Network Control Architecture

The first prototype of the Rendez-vous Point (RDVP) Server and Client was completed today.

This is a network communication scheme that aims to answer some of the basic questions that come up about communication between different devices.  Namely how do they find one another and communicate?

Objectives include:

• Minimal or no configuration
• Maximize discovery of services and capabilities
• Common protocol
• Easily extensible
• Interface available to wide variety of devices
• Agnostic as to whether operating on local network or internet

Some of the first uses intended include:

• Discovery mechanism for purposes of WebRTC
• Signalling mechanism for purposes of WebRTC
• Remote control of Pi locally or over internet

The basic principles are:

• There is a centralized server (the RDVP Server)
• Everything connects to it
• Password protected
• Primary functions include:
• Act as a transparent bridge between clients who want to communicate directly.
• Allow Admin control
• Present web interface
• Enforce tightly-defined roles
• Three tightly-defined roles for systems connecting in:
• Admin Client
• Speaks RDVP protocol (JSON over WebSockets)
• Can monitor and control activities and state of Server
• Likely spawned from web interface, but also possibly from other system such as those implemented in Python in the first prototype client.
• Server Client
• States ID and waits for messages to be sent to it, which it will respond to as-appropriate.
• No messages will be sent to the Server Client unless a Client Client indicates a desire to connect to it, and the RDVP Server bridges them.
• Client Client
• States ID and intended Server Client to connect to.
• Connection to Server Client will immediately be bridged or this client will be rejected and closed.

The expected use of the above is:

• Server Clients might be anything "dumb" (like a Pi program) which is waiting to be controlled but doesn't know by who.  Simply announce itself and wait.  This also makes internet communication and control possible since the RDVP Server can easily live on the internet.
• Client Clients are expected to be initiated from more knowledgeable control mechanisms.  This might be from a web interface, or other purpose-built mechanism.
• Admin Clients are meant for systems which want to discover Server Clients to connect to, or otherwise observe state.

Having a central server which brokers communication also allows for snooping of communication as well as control over systems connecting in.

Future projects should be able to make use of this scheme as well.

A very specific first-use-case will be attempting to initiate WebRTC with the UV4L server.

This UV4L server is a bit opaque but does have a webserver which also responds to WebSocket connections leading to a WebRTC connection.

I don't want the webpage, I just want it to give up its video stream.  In the diagram which follows, there is a bridge between the UV4L server and the RDVP server.  This is essentially a male-to-male connection which itself is a bridge, making connection to the UV4L server possible remotely.

Here is a rough architecture diagram:

Pi SSH Disconnects and Power Management

Solved an ongoing issue with the Pi, and that is I often come back to my computer with all of my SSH terminals disconnected.

I would log back in again, and check that the uptime was still days whereas I had been away for much less than that.  So I concluded the Pi hadn't rebooted, thereby disconnecting the terminals.

It always seemed to be after a somewhat lengthy time away, but sometimes not all that long (like a few hours).

I thought first it was possibly idle connections being cut.  I played around with some settings but it didn't really do much.

After some reading online, I decided to try looking into power management on the WiFi adapter.  This was the solution.  The stackexchange discussion which led me to the solution is here (link).

The adapter I use is the recommended adapter noted in a prior post (link).

The commands required are seen below.

$ iwconfig
wlan0     IEEE 802.11bgn  ESSID:"DV_2.4Ghz"
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:81:D8:D5:46:3C
          Bit Rate=5.5 Mb/s   Tx-Power=1496 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=70/70  Signal level=-34 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

$ sudo iwconfig wlan0 power off

$ iwconfig
wlan0     IEEE 802.11bgn  ESSID:"DV_2.4Ghz"
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:81:D8:D5:46:3C
          Bit Rate=5.5 Mb/s   Tx-Power=1496 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=70/70  Signal level=-33 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

After having run this command, the issue has not come up again.

A persistent on-boot configuration will likely be required.  I doubt this command stays in effect across reboots.

Network Servo Control Demo

Now that my WebSockets libraries are working better, I decided to try to use them in a program which can control a Servo.

To make the demo more interesting, I strapped a webcam to the top of the servo so I could use it like a DIY security cam.

The servo controlling software opens a WebSocket port to listen for incoming messages.  For now, the messages are simple -- A number, which represents the percent of range of motion of the servo.

So if you send 50, that means 50% of the range of motion, and the program will instruct the servo to move there.

To send messages to the servo controller, I use a super simple program written to bridge stdio to WebSocket connection, basically a WebSocket 'telnet'.  This is my wsEndpoint program.

Feeding into the wsEndpoint is stdio, but now controlled by a 'tk' gui program showing the numbers 1-100.  Click the number, it prints the number to stdout, which is relayed over the WebSocket connection, and the servo moves.

In the screenshot above you can see a washed-out square image on the screen, that is the grid of numbers.

The webcam in this demo is hooked up to my laptop, not the Pi.  No WebRTC involved here.

Network Control of the Pi (WebSockets) 2

Some success with WebSockets, finally.

I shied away from using asyncio support for WebSockets for several reasons:

• I don't know much Python programming and don't understand the examples
• It seems to be a much lower-level implementation than I want (maybe mistaken)
• I don't want to require Python 3.4, which is required for asyncio.  I want to be able to use Python 2.7 in the event that I get some less-capable or less-modern devices involved.

I tried several libraries, and in the end had difficulty getting them to work properly on Pi.

In the end I fell back to use Tornado libraries, which is among many things, lets you implement and use:

• An event manager
• WebServer libs
• WebSocket client libs

With these I've been able to build a basic set of libraries which allow me to write very short Python programs which can:

• Listen on arbitrary WebSocket addresses (eg ws://127.0.01:4000/).
• Connect to any arbitrary WebSocket adddress.
• Handle console input while doing any of the above.
• Do all of the above via an Event Loop, no blocking required.

Difficulties came up understanding how various events fire in association with WebSocket connections working, etc, and how that fit into the interface I wanted to build.

An example being - What if your program tries to connect outbound (async) and wants to cancel the attempt before finding out whether it worked.  Not supported (from what I can tell).  I had to implement a wrapper to fake it.

Network Control of the Pi (WebSockets)

I don't know what the specific architecture will be for control of the Pi over the network.

However, it does appear likely at the moment that:

• Python will be involved
• WebRTC will be involved (in some cases)
• Browsers will be involved

This leads me to consider WebSockets, which is bi-directional message passing, supported by Browsers, and also now naively by Python and other languages.

Python is in scope due to it being the language of choice on the Pi, and is covered by a number of libraries which claim WebSocket support.

WebRTC is in scope due to the requirement for "Signalling," which is the discovery and transfer of media/network details.  This can easily be done over WebSockets, and is seemingly commonly done that way.

Browsers are in scope since any control systems put together would be much nicer with a point-and-click interface, and Browsers are perfect for this.

So, I have deiced to learn how to implement, in Python, some libraries which can act as the middleware between my Pi and the internet (probably a relay of some sort for WebRTC Signalling).

Also any process-to-process communication on the Pi can be done over WebSockets because why not.  Keep it all simple and hopefully make the testing easier as well.

Circuits

I'm not very experienced with Circuits or Electricity.

I've read about it in the past and tried various little experiments but I have no particular experience beyond that.

In the past my emphasis had been to learn about how electricity worked.  Here I'd like to simply apply basic circuits to build remote-controlled mechanisms.  So the focus has changed.

With the Pi I have to now care about:

• Controlling circuits.
• Not blowing up the Pi as a result of wiring up a circuit to it.

My initial attempt was to try to control an SG90 Servo from the Pi.

I wired it up directly to the GPIO pins and the power, and the servo moved around a bit and then the whole Raspberry Pi rebooted.

I wasn't sure why because there were videos online of people doing exactly that with no issue.

I thought perhaps the Pi was being affected by the electrical noise and feedback of the motor, so I built a protection circuit to isolate the Pi.  This did not work.

After more thinking and searching, I concluded that perhaps the motor was exceeding the total power output of the wall adapter I was using.

After looking, I found that the adapter I was using produced 5V at 750mA.  I replaced it with one providing 5V at 1100mA, and the problem of rebooting has not come back again.

I will keep the protection circuit in place just for good measure.

Video on the Pi, and over the Network (with WebRTC)

It'd be nice to have the Pi able to:

• Operate a camera (webcam)
• Relay the video over the network

Thinking about this, I'd like to do as little work as possible on the video.  I don't know much about encoding/decoding, but I do know it's CPU intensive (something I don't have much of on the Pi).

Therefore I'd like to do minimal work but be able to kick a video stream out over the network.

It made me think of WebRTC, a web-standard peer-to-peer media transfer mechanism.  Used in several places include Google Hangouts.  I didn't know much about it so I researched it.

In short, a WebRTC endpoint (like a web browser) will want to establish a peer-to-peer connection with another endpoint.  This entails:

• Discovering another endpoint (not part of the standard, you implement this)
• Exchanging details about media capabilities, and network / NAT details (details acquired by API, but still up to you to implement the transfer.
• Attempt direct-connection (API handles this, but you need to provide STUN server details)
• Javascript (or other language) then is provided with a stream of media content (like video) which can be directed to the screen (like a <video> tag 'src' attribute in a browser).

This seems promising on the Pi side if there is a non-browser implementation.  And there is.

Hunting around there appears to be several mentions of WebRTC and Python and Pi, including OpenWebRTC, and others.

However, the most successful path I could find online appeared to be message boards discussing the UV4L (Userspace Video 4 Linux) implementation of WebRTC and interface via a WebServer.

Another post will include detail on attempts to set up and use.

Resources about WebRTC:

• WebRTC Demo (link)
• WebRTC Tutorial - Infrastructure (link)
• WebRTC Basics (link)

Resources about UV4L:

• UV4L Announcement about supporting WebRTC (link)
• UV4L Instructions on use (link)

Raspberry Pi 2 Setup Notes

Took a micro SD, not a regular SD.  Had to buy a few of those.

The raspbian OS install wasn't so bad.

Keyboard is in UK setup, which took a googling to figure out how to change.  Various utilities don't seem to be there, such as telnet.

I bought the wifi dongle to go with it (since my intention is to try to operate it over the network, and subsequently the internet).

Setting up the wifi wasn't too bad but involved setting up a config file with my network and password.  Despite the dongle being 2.4GHz and 5GHz capable, my 5GHz network wasn't detected.

Setup details can be found (here).

Prototyping Platform

For controlling electronic devices, I've decided to try to use a Raspberry Pi.

I had tried an Arduino in the past and found it was a bit annoying to deal with having to re-program regularly with their flashing device and the serial/usb monitor, etc.

Raspberry Pi I believe is a much more powerful device that you can run Python (interpreted, no compile, lots of modules), and even a monitor on it.

Overall, I am not looking to challenge myself regarding the platform, I want to learn the electronics.

In the end I have purchased a Raspberry Pi 2, which is a quad-core Arm 7 processor with 1G RAM.

If I later think it's overkill, I can get other control systems.

Getting Started

I read about some of the Google and Amazon package delivery drones a few weeks ago and I've been interested in learning more about what drones are and why they're in the news so much.

I spent a weekend reading up about hobby fliers, what they fly, and what technology they use to it.

Seems that the hobby breaks down in a few dimensions such as:

• Fixed-wing versus quad copter.
• FPV or not.
• Long distance or not.

Some of the technology behind these systems is very impressive.

High-end radio control systems can operate these craft 100km away.  The video systems can transmit real-time video back to the operator to control at those distances.  Notably the video the operator sees in real-time isn't what gets published online, that's a HD camera strapped to the nose, what they see is fairly grainy.

Quad copters and even fixed-wing seem to have a number of sensors which assist with balance and control in-range, as well as auto-pilot systems and fail-safes which return the craft home if it goes out of range.


I think controlling these devices at long-range is interesting.  Some of the articles I read about Google and Amazon indicate that control over the internet may be the way those systems operate.

Control over the internet at long-distance seems plausible provided they're staying at an altitude which still receives service, which the 500ft ceiling seems likely to.

I'd like to play around with some of the technology at use here so this blog was created to keep notes and mark progress.

My aim is to learn to control various related electronics, locally and remotely over the internet.  Hopefully in learning these devices I will increase my familiarity with circuits and control systems, and interesting or useful ideas will come to mind about how to apply them.

This blog was created Nov 28, 2015, when I had actually started reading around Nov 14, 2015.