So after the “serial over USB” problems (see last post), we removed USB completely, switching over to use the built in UART port on the Raspberry Pi and connecting direct to another serial port on the Due (it has lots!). Both devices run at 3.3 volts, so only 3 wires are needed – Tx, Rx and Gnd. A quick search and replace and recompile of the Due code to change the port it is listening to and we fired up the code again – and it worked!
Here’s video of us driving it round the office under joystick control:
Our design calls for an Arduino (to allow real-time stuff like outputting steps, running control loops, etc). We’re using an Arduino Due.
We had planned to get the Raspberry Pi to talk to the Due over ‘serial over USB’ – i.e. we connect the USB port on the Due into the Pi and then send bytes to the /dev/ttyACM0 device that gets created by the OS.
This worked, but after a while (30s or so of chatter) the port would stop responding. A quick google showed that a few other people have seen similar behaviour, but no one had a solution. 🙁
Now to find a workaround…
The plan here is to get last year’s Metabot code (with as few changes as possible) working on the new robot so that we can try it out and check the performance is sufficient. If we need new motors shipped from China, I’d like to know now rather than halfway through November!
The first 2 bytes in each frame are sync bytes (0x03, 0x01), then there are 7 pairs of bytes which tell you the position of each of the transmitter channels (joystick axes). Just read the bytes and make your robot dance! 🙂
At first glance, the straight line speed test sounds like an easy event. But once you try it, you start to notice problems:
Robots don’t go straight naturally. There’s always some difference in the wheels, motors, speed controllers, etc so that the robot starts turning. And over the long, narrow speed test course, you’ll probably hit the walls at some point. So how can you deal with this?
Drive under manual control
This is harder than it looks – most robots last year didn’t have fine direction control.
Detect the walls and avoid them
This is a good option – detect the walls somehow (e.g. with an IR or ultrasound sensor – much like the proximity alert sensors, but mounted facing sideways) and if you see one, either speed up the wheel on that side or slow down the one on the other side.
Mechanically follow the wall
This is what we did last year with metabot
Place some sort of bumper (wood, teflon, bearings?) on the sides below the top of the wall
and optionally place the robot against the wall on the side it naturally turns towards
The downside of course is that this increases friction
Write code to process the image, spot the edges of the course and adjust the motors appropriately.
Image processing code is hard… People have used OpenCV with the RPi.
Regularly read it and adjust the motor speeds if it detects that you’re turning
BUT – I’ve never tried this myself and I don’t know for sure that the compass will be sensitive enough to detect the very small rotations you’ll need to spot, or will work well in the presence of the magnets in your motors!
Finally – think about how you’re going to stop… If your robot is capable of any decent speed, the stopping area is quite short. We implemented a “dead mans handle” on Metabot last year – i.e. the robot ran at full speed while we held down the button and stopped immediately when the button was released. The event judge ruled that this was a safety device and NOT manual control in case that matters to you.