Sunday, August 15, 2010


You can probably tell from the first video that Twitch, Jr. is not the easiest robot to drive. Trying to remember which way is forward is just the beginning of the problem. (Which way is forward?) There is also bit of variance between the relative speeds of each motor under the same nominal command. This gets exaggerated by the 4WD omni wheel configuration, especially on an uneven surface.

Here's where a gyro (yaw rate sensor) comes in handy. These tiny MEMS sensors measure angular velocity and produce an analog signal. The signal can be processed by a controller for tasks such as self-balancing, or level flight. In the case of Twitch, I really just want it to keep the robot on a fixed heading unless I tell it to rotate. This should be a simple feedback controller. I learned about that in 2.00...wait actually I did it in high school.


Anyway, six years of training later and it shouldn't be that hard to create a yaw-rate stabilized robot, right? Right?

Well, where do I start? First problem: Twitch's original control mapping software resided on the transmitter side, in the Visual Basic program that interfaces with the USB gamepad. In order to integrate the yaw-rate control loop, the entire mapping algorithm, including the state machine that sets which driving mode is active, had to be moved onto the microcontroller. Okay, this was mostly just tedious, not really difficult. Then I soldered on some more headers in empty protoboard space and added the sensor, a Sparkfun breakout of the LPY530AL 300º/s gyro.

Except, Twitch has a densely-packed electronics bay already, so it's gonna be a tight fit.

 See the headers?

Things had to bend a little, but everything seemed to still work. So, I uploaded the new mapping code with the yaw rate control loop and put it on the ground for some testing. After swapping to sideways mode, though, the receiver radio died. :( I've only killed an XBee radio once before and that was by applying 12VAC to it... So something very bad must have happened. Upon further inspection:

There you can see the radio and a small bit of the gyro in the upper-left corner of the image. You can also make out the plastic back of a Mabuchi motor and a piece of electrical tape. The electrical tape I put there later to cover the exposed motor terminal, which happened to just barely intersect the 3.3V and GND pins on the gyro when the motor swung over into sideways mode. So, the switching 8V line to the motor got momentarily switched onto 3.3V and/or GND. Amazingly, the gyro survived. But the radio did not. After bending the tab out of an interfering path, covering it with electrical tape, and replacing the radio, Twitch was back in business:

The yaw-rate stabilization definitely helps. By request I also added a mode that automatically selects the wheel position based on where the translation joystick is. Actually, this is how I meant to do it originally, I was just lazy and had buttons for changing wheel positions instead. But, now it's much closer to fulfilling the original vision.


  1. Then make a large one with a shopping cart on it.

  2. but you guys need money to make a shopping cart version! Sell the prototype of thing call "Citycar" on eBay for financing.

  3. Do you not run into problems with Gyro drift?

  4. Or we can use this as the base for the 1/10th-scale demo City Car like I've been suggesting. I would have to make it fold, though. How do you fold a linkage? The only thing I could think of was cable-actuated half-linkages.

    Yes, the gyro will drift over time, but with enough trimming you can get it to be less than a few degrees per second, which is fine for driving a robot. To do better I would need a compass, and I'm not going there.

  5. Did the RC high pass filter on the gyro breakout board give you any grief? In my project I eventually decided to disable it with a soldering iron -- it made it impossible to integrate rate for heading. Perhaps for stabilizing around a straight trajectory it doesn't matter as much?

  6. I know of that problem. Not sure what it looks like in terms of physical results. Maybe that's why the robot keeps spinning sometimes. I will try removing it since I don't think it's giving me anything that I want.

    It looks like the filter time constant is 4.7s, so that if you start and end a rotation command within ~1s or so, it should still be "integratable." Don't expect it to turn exactly 90º or anything, though.

    They're probably hinting that the gyro can't be used for long-term heading stabilization anyway due to drift. But even a drift of 1-2º/second, which should be possible with good calibration, is preferable to the high-passed signal, which can't give even an approximate heading after 4 seconds. shows how you can use the high-passed signal and another absolute reference (compass?) to create a much better absolute estimate. But without the compass, the best you can do is trim the gyro very carefully and live with the drift.

  7. is no longer alive -- can you post it somewhere else?

    1. New file locations here: