User Interface

I decided I should post some of the UI and hopefully some video; this is after all, or should be, a very video and UI-heavy project. Work on the hardware side has left the software side behind.

So here is a screenshot of my current basic UI! Click for the full-size version.

The camera view is shown with EasyCapViewer (mac) or AmCap (Windows). Processing is used to create a basic control and indicator interface between the user and the serial port. 

Let's break down that UI a bit:

The camera is controlled by moving the mouse cursor within this grey box. The mouse position is mapped to degrees for the servos; left is as far as the pan servo will turn left, middle is straight forward, at the bottom is as far as the tilt servo can go down. This is not ideal as the mouse can go out of the box while you're watching the video, and you have no idea of absolute position; I often look down to see where the bonnet of the car is so I can tell where it's pointing!

The 4 squares at the top indicate the movement that should occur; basically they map the WASD keys to forward, back, left and right; they turn yellow when the relevant key is pressed. This was used for debugging.

Next the two V labels indicate voltages sent back by the arduino every second. Vcc is the inbuilt voltage meter of the arduino and Vcar is the voltage of the car battery, max 6V, which is input with a 1/3 voltage divider so that the arduino could even read 9V if I was running it at 3.3V. It cannot read a voltage above Vcc. There can be variation in these voltages near max capacity, but as it is currently well below that they are the same.

There is a text box which allows me to type any command to the arduino; currently it uses a simple string-based command system which is easy to debug but not the most efficient. It might be improved later but works for now.

Finally the ping time; yes, latency! It measures the round-trip time of a timestamped message to be sent, received and processed by the full stack, sent every second. One of the first things I implemented with the string-based command system was an echo response, so this sends a message of "ping <current-time>" where current-time is the number of ms since the program was started. When an echo is received, it compares the time in the message with the current time and there is your latency. The latency bounces between 33 and 66ms at the moment; I have another post to write about that. It does not measure lost packets, but if it has been over a second since it received a ping echo, it says "Ping timeout!!"

As for the video, well, it's not great, but I'm actually pretty impressed given the amount I paid for it all! There is some bands of interference near the top and bottom of the image; this is due to the wireless transmission. Bypassing the wireless makes the image clearer. But there should be a better wireless camera kit on the way.

So this is far from ideal. I want the video fullscreen, with the mouse free to move anywhere, I want the voltages and latency overlaid on the video like a HUD, and I want some graphics to indicate camera angle overlaid as well. There will be more overlays later too.

I met a new guy at Hackerspace who has experience with doing games and video programming and is interested in the project, which is great! He's a Windows guy, which is less great, but we'll figure it out :) So hopefully I will get some of this improved soon.

Need to fix up the camera feed

The biggest current problems I have with Phase 1 are just around video, mainly due to buying cheap shit electronics from China - the camera image itself is surprisingly clear, but the refresh rate is low and you can't see anything when there's vibration (ie driving fast). I have ordered a much better camera and mounting system from hobbyking, but seems they're waiting for stock to come in.

And then there's the very cheap USB video capture devices I bought - they were so cheap I got 4 for $36 including shipping! They're apparently DC60 devices; DC60+ are apparently *completely* different and do work on mac and better in general. That's probably why they were so cheap. They're ok for just checking what the camera is seeing, but the driver support is very low, there are no drivers for mac, so I can't write a program to integrate the video from it. There is only one decent program I've found that lets you see the image, EasyCapViewer, which is a mac port of a Linux driver. Unfortunately, it's only a standalone program, and doesn't create devices I could use in another program. And it's written in some language I don't know which uses .m source files - Objective-C maybe? I would rather write in Python or even Java. I've hacked up a basic UI in Processing but it doesn't integrate with the video at all.

So I'm also looking for better capture devices but everything on ebay is variations of the same chip. Also everything is geared towards either viewing your console game in real time or capturing VHS tapes to DVD, so there aren't general drivers that you could plug into any software. Nothing seems available in USB which is a shame because I wanted to use my laptop so I can move around with it. I will try a PC video card capture just to see if that works better.

Servo control and Arduino PWM outputs

tl;dr Arduino PWM (ie analogWrite) doesn't work for servos. Use the built-in Servo library or one of the many variations and deal with the loss of some analog output pins or having to call a function at least every 50ms.

I had problems with the servos being a bit jerky, or twitchy when not being moved. I'm using the built-in Servo library, but was annoyed that it disabled PWM outputs on some pins - I used these pins for the motor control, and this particular issue wasted several hours debugging. After I discovered this, I was annoyed because I had found a convenient place to plug in motor control and was too lazy to move it.

I tried the SoftwareServo library and found it no better, in fact possibly more twitchy, sometimes not responding at all - but this may have been due to power problems. But I put a LED on the output pin and it seemed to flicker inconsistently, due to it not being a hardware output and dependent on processing loop time, whereas it should have been a smooth or at least consistent flicker.

I thought all this was silly, why were there different libraries for servo control, and both had annoying issues? I could just control the servos directly with the hardware PWM, right?

Well I tried just that, and the servos did very weird and completely wrong things - a single change it degree made it move a little, or maybe 90 degrees.

Turns out that servo motors are not controlled by PWM, or Pulse Width Modulation, at least that which is output by the Arduino (the timing is probably wrong). They are controlled by Pulse Position Modulation (PPM). The wikipedia page on servos is a little misleading on this matter, although it is possible there are servos that are controlled by different kinds of PWM.

All this behavior finally became clear when I found this post on the arduino forums: 

Help with PWM for controlling servos and speed con

So after moving my motor PWM pins, making sure the arduino power was isolated from the servo power, replacing the oversized pan servo with a smaller, faster, lower-power one, and replacing the tilt servo with one that hadn't been put through the first batch of testing where it held up the camera itself, I have a stable camera :)