The EMF Roamer

Posted on by

While packing for EMFcamp 2018, I came across a small tracked robot chassis at the back of my cupboard. It was instantly obvious that this needed to be turned into a small internet controlled robot for the camp. It could be deployed and roam around the site, controlled by anyone!

Just allowing people to drive it line of sight wasn’t good enough! Especially not in the world of raspberry pi’s. The video from a raspi camera should be streamed to the user while they have control. A GPS module showing a roamer icon on the official EMF map was also a must-have at this point.

A free for all in terms of control would also be a mess, so we devised a queue system. People could join the queue in their web browser and wait their turn, or provide a mobile phone number to receive an SMS when their turn is up (thanks nexmo!). We also planned twitter integration, but didn’t get our account approved for developer use until after the event. Cheers twitter. The queue system was hosted by Hostgator ,but it ground to a painfully slow halt where pages took almost 60 seconds to use, forcing us to move the whole thing over to Servage. I think I will be ditching Hostgator soon after this experience.

The first step was to get a low latency video stream working. Youtube does offer a low latency mode, but I found that it still had a latency of 5-10 seconds. Nowhere near good enough for live control! Youtube streaming was however still a nice idea, as it would allow people to watch the stream as they wait in the queue. Step in MJPEG-Streamer. It can produce a stream with extremely low latency. Perfectly good enough for control. The only difficulty being that once the MJPEG streamer was using the raspi camera, it was then locked and could not be used by other programs.

Step in horrendous FFMPEG commands! After far too much poking around online, with lots of commands that didn’t work, or did something slightly different that broke when I tried to modify them, I found a winning combination. FFMPEG picks up the MJPEG stream, adds a fake audio source (required for youtube), and sends it out to the youtube ingest server over RTMP. This FFMPEG command sat inside a shell script that would monitor the log, and restart the process if no new frames were sent in a few seconds.

My initial plan for controlling the motors was to run an HTTP server on the pi, and control the GPIO pins depending on which directories were accessed. This was accomplished through a python/flask script. The motors themselves are controlled by a [chip] H bridge driver chip.

The GPS side of things was pretty trivial using this python port of TinyGPS. The data is sent to a webserver via GET where it is then stored in the MySQL database. The official EMF map was open source, but after a couple of days of trying, we were’t able to integrate a roamer icon on to the map nicely. Instead as a last minute bodge, I centred an icon on top of the map in straight up HTML, and repositioned the map to reflect the position.

In order to get the best possible WiFi coverage and quality, we purchased a high gain antenna/adaptor from Amazon, which was supposedly Pi compatible. This worked on my home WiFi, but actually felt more laggy than the el-cheapo Netgear adaptor we were initially using.

When we arrived at emfcamp, the fancy WiFi adaptor just flat out refused to connect to either their legacy or insecure 2.4GHz networks. I can only put this down to an incompatibility with WPA2 enterprise. This can apparently be fixed by recompiling some drivers, if you have the patience. We did not have the patience, so taped the Netgear adaptor to the high gain antenna on a USB extender. Coverage was a little patchy, and it was unreachable for several seconds when it roamed between AP’s.

This patchy WiFi performance was a massive problem to the controls. Sometimes the stop packet was lost in transit, and the motors would lock on moving in a direction. To try to mitigate this, I had programmed a 3 second dead mans switch, which would stop the motors if no new packers were received. Three seconds of driving in a random direction however was a pretty poor experience. I quickly replaced the HTTP control with websockets, and the results seemed much better. I was able to reduce the dead mans switch to one second, and it seemed to be needed less often.

All of these scrips were started using cron jobs to run @reboot.

Tiny tracks and long grass were a terrible idea. Initially you were able to turn on the spot by driving one motor forwards, and the other back. I ended up disabling this as it caused the tracks to ingest way too much grass, and was probably the main culprit to us shredding the first gearbox. It also fell over at almost any opportunity.

This however did not stop one keen driver from taking it for a lap around the Hacky Racers track, and officially scoring the worst time of the entire event.

Some stats:

  • GPS updates: 1632
  • Distance driven: 3.217918922 miles
  • Number of attempted users: 307
  • Number of users who drove: 253 (including us testing it)
  • Number of unique drivers: 116
  • Hours of video: 6:19:29
  • Number of talks crashed: 2 (stage A, first one here, second one not captured)
  • Number of times the tracks came off: >2
  • Number of times people tweeted it wasn’t working: 6
  • Time it took to load the homepage on our old shared webhost: 30-60 seconds
  • Official hacky racers lap time: 6:42 (slowest of the whole weekend)

 

Improvements:

  • Bigger chassis, bigger tracks, or just wheels.
  • Diversity WiFi antenna. Use a bridge to LAN?
  • Timestamp video (aligning patch YouTube DVR with GPS was a nightmare).
  • Make the map less broken.
  • Night vision camera.
  • Something to discourage people from standing in front.
  • Battery voltage monitoring.
  • RF gateway from wired server for remote control (LORA?)
  • Moar RGB
  • Some kind of game. Collect/chase things on the map?

I used Excel 3D Maps to produce the map animation from CSV GPS logs.

Leave a Reply

Your email address will not be published. Required fields are marked *