Assembling the self-balancing robot

Well, Alan and I both got tired of waiting for me to finish the modeling and simulation I wanted to do, so I threw caution to the winds and ordered all the parts to build my draft design of the self-balancing robot. There is still the chance that the motors may not have sufficient speed or torque, or may have too much backlash to work well. Also, I went ahead and ordered the cheapest accelerometer available at Sparkfun, (the MMA7260) reasoning that we’d have a go at making it work first. We can always switch to a different sensor or add additional sensors if we have to.

So now Alan is spending this weekend assembling the robot. I have written Rev 1 of the software, and soon we will be putting them together for our first trial runs. For Rev 1, we are not going to try to balance. We have put a small caster on the front of the box so it can drive around as a typical three wheel vehicle. Once we debug the motor control and get a feel for the speed and torque we have available, I will be back trying to develop the balancing control software.

In the meantime I have been testing the accelerometer and, true to everyone’s comments, the measurements are alarmingly noisy. Of course the signal can be filtered, but that introduces delay in the measurements. Whether we can get this to work or not will depend, I think, in large measure on how rapidly the main control loop has to run to keep the robot well balanced. The MMA7260 has a refresh frequency on the X and Y axes of 350 Hz. So you get a new reading about every 3 milliseconds. If we can afford to make corrections to the motor inputs only every 30 ms, say, then we can take the average of the last 10 readings to smooth out the acceleration data. If this turns out to be too slow, the robot will be unsteady and we’ll see lots of random jittering back and forth. On the other hand, noisy acceleration data will cause jittering, too. So we must find the best tradeoff. But I note with some unease that there is still significant noise in the data even after averaging over 10 readings. And, of course, the more heavily the signal is filtered the more delay it creates before the control algorithm will see the beginning of an excursion. This can cause oscillation or even a loss of control. I’ll try to post some specific data at some point so you can see what I’m talking about.

Alan and I have had a number of discussions about whether we needed wheel encoders so we can get feedback on the distance traveled by the robot. We are going to build it first without encoders. This, too, is heresy among self-balancing robot builders (uh, I mean builders of self-balancing robots). Partly the standard wisdom arises from how people conceptualize the inverted pendulum problem. The natural way to think about it is that I measure how far the pendulum has departed from vertical, then I move the base that far to get it back under the center of gravity. But of course, for balancing, you get all the position feedback you need from the pendulum itself. However, the more fundamental reason people assume you need encoders is that the accelerometers can’t tell you whether you’re moving, only whether you’re accelerating. There is no way to correct the inevitable error you get from computing velocity by integrating acceleration. So when the robot is commanded to stand still it has no way to be sure it really is, and when it is commanded to move at a certain speed it has no way to determine that either.

My solution to this problem is partly electrical and partly anthropic, if you will. One piece of data we do have is the average current being supplied to the two motors in the forward and backward directions. To some approximation, you expect that if the robot is sitting still on a level surface the average power in each direction will be equal. Of course, there are natural physical irregularities so that is not exactly correct. But I believe we can add a bias term to that balance and treat it as a tuning parameter. We can adjust it to correct for (almost all of?) the drift. That’s the electrical part. The other part is based on the idea that this is not actually an autonomous vehicle. It is just a fancy remote control car. So the human in the loop will be controlling the position and speed to their satisfaction. Of course, this approach does have another downside: the robot will not be able to maintain position on a slope by itself. It will slowly roll downhill. But I think this will seem like a very natural behavior to the human operator, and of course they will compensate.

The only real question, which we’ll find out by building the thing, is how well the drift can be corrected with a constant bias, that is, how stable the bias is. Just in case, though, I bought some optical encoders and eventually I expect we’ll get around to fooling with them – if not on this vehicle, then on the next.

We’ll have another report, with pictures, when Alan finishes construction. I can’t wait!

IR Receiver Circuit

The IR receiver from Mouser Electronics arrived this week. It came amazingly quickly. I ordered it late Saturday night. It shipped on Monday and was delivered on Tuesday. The chip we are using is the Vishay TSOP4840, which is only $1.10 quantity one at Mouser. Alan built the test circuit to connect the IR receiver to the Arduino microcontroller board using a breadboard:


Here's a closeup of the IR receiver and the remote control.


Here is the schematic for the test circuit:

The Sony remote control modulates the IR carrier wave at 40 kHz. (Other manufacturers use other frequencies. 38 kHz is common.) This carrier wave is turned on and off to create a stream of pulses that carry the data. The SIRC protocol uses pulse width modulation. A command begins with a start bit that is 2400 µs wide. It is followed by twelve data bits, separated by 600 µs gaps. A logical one bit is represented by a 1200 µs pulse and a logical zero is represented by a 600 µs pulse. The TSOP4840 demodulates the IR carrier wave and presents a logical signal on the output pin that is low when the IR carrier is present and high when it is absent (i.e., active low). The output is connected to a digital I/O pin on the Arduino. D2 is chosen because it is one of two pins that can generate hardware interrupts when the value changes. Thus it is only necessary for the software to time the intervals between the interrupts to decode the signal. I set to work on the software and we got the whole thing working without too much trouble.

It’s amazing how sensitive the receiver is. You can be across the room and point the remote at the opposite wall and it will still pick up the reflected signal. This will work great for the robot. You will have to be standing behind it, but the direction and distance are not critical.

The nice thing about using a standard IR remote control is how many different buttons it has. Once you’ve got the software in place to decode the commands you can define as many commands for the robot as you would like. We expect to have at least seven: stand up, lie down, go forward, go back, turn left, turn right and stop. One interesting issue is that the remote control repeats the command every 45 ms for as long as you hold down the button. It turns out to be essentially impossible to tap a button quickly enough to send only one command. Two or three is more typical. The robot control software will have to determine when a command was doubled or tripled through an auto-repeat and compensate.

Next up is to go back and finish the physics model and the simulation. I set it aside last week when I got stuck, but I’ve asked my brother-in-law, whose degree is in physics, to help me. So it’s back to school for me this week!

Bubbling to the Surface

It is time to confess a new obsession. Like most obsessions it begins by contagion. I caught this one from my son Alan. We are going to build a robot. Well, not exactly. We want to build a remote-controlled self-balancing two-wheeled vehicle. Think Segway, only very small. And hyphenated. It's not an original idea, of course. Besides Segway, lots of amateurs have built such things. To the extent that we have a new twist on the concept, I am interested in seeing how cheaply we can do this. I think we might be able to do it for under $100. Most such projects seem to be at least $200-300. Cheap also means small (smaller motors cost less) so ours will be smaller than the others.

I am not a hardware guy. I'm like the punchline of the old programmer joke: How many programmers does it take to change a light bulb? None. "Hey, man, that's hardware!" Fortunately for our collaboration, Alan is much more of a hands-on kind of guy. In fact, I think we make a great team. I can't wait to take a crack at the control algorithm and he's itching to do all the soldering and wiring and assembly.

Here's how we got into this. For several months Alan has been surfing websites for DIY electronics projects. For Christmas he asked for an Arduino, an inexpensive microcontroller board based on an open source hardware design. Until Alan asked for this I never knew such things existed. Then I started doing a little investigation, and the obsession began. It is such a great time to get involved in DIY electronics. I had no idea there were so many sophisticated components available so cheaply, like three axis accelerometers in an IC chip that costs only $10 or $20 dollars. And the programming reminds me of the old days programming for my first home computer: an Apple II. Low level coding on an 8 bit micro and direct manipulation of the hardware. Wonderful! (That's geek nostalgia, friend.)

I see this effort as a sequence of sub-projects:

1. Do a preliminary hardware design
2. Develop a physics model for simulating the vehicle
3. Use the simulation to develop and test the control algorithm
4. Develop an IR remote control decoder to control the vehicle
5. Build rev 1 of the vehicle as a three-wheeled scooter
6. Debug and tune the balancing on two wheels

I've already roughed out the hardware design with an eye toward selecting and pricing components online. The only piece I haven't figured out yet is how to cheaply measure distance traveled. The obvious answer is an optical wheel encoder, which you can buy as a kit for DIY robotics. But if we're going to keep the hardware budget under $100, we'll probably need to do something cheap and homebrew.

Most folks who have built one of these things uses both a gyro and an accelerometer. The gyro gives a stable rate signal that you can integrate to get angular position, but it is subject to a lot of drift. The accelerometer gives a very noisy signal, but it can be filtered and used to correct the gyro drift. Again, to save money I'd like to try to make our vehicle work with just an accelerometer. I want to use the simulation to see how much noise I can tolerate, and get a sense for the bandwidth and resolution I need on the accelerometer. This past week I've been working on the physics model. Boy, my freshman physics is rusty! I suppose since it's been nearly 35 years that's not too surprising. I've been beating my head against it for days.

At the same time I've been reading up on IR remote controls. We want to use a Sony remote from our DVD player to control the vehicle. You can buy an IR receiver for $1 or $2 but I'll need to study up the SIRC protocol and program the Arduino to decode the signal. Last night I ordered the part and started looking into the programming.

Well, that's where we are so far. I have in mind to post sporadic progress reports here as we move forward. If we ever get it working I'll post a few video clips, too. Now that I've posted this entry the pressure is on to actually do something!

Word of the Day - Snarge

Lately the airwaves have been filled with news about the US Airways pilot who made the miraculous emergency landing on the Hudson river after hitting a flock of geese. We've all been amazed by the stories and pictures. It's been educational, too. Many people didn't realize that a few birds can bring down a big jet. That angle of the story leads to today's word of the day:

Snarge - what remains of a bird after it strikes a plane.

Birds are actually a significant hazard in aviation and crashes of this sort occur regularly. So regularly that there is a lab at the Smithsonian Institution for identifying the bird species from whatever goo and feathers is left. This information helps experts understand how to improve the safety of airplanes and airports. And who heads the Feather Identification Lab at the Smithsonian? Her name is Carla Dove! Gotta love that.

Glow in the Dark Toys

Back when I was in college the only thing you were likely to find in a dorm room that glowed in the dark was a black light poster. Or a doobie. Now here's a guy named Andrew Seltzman who graduated this year from Georgia Tech and what's he got in his dorm room? A fusion reactor! Yes, that's right. He built a fusion reactor in his dorm room. Here's a picture of the deuterium ion injector parts all laid out on his bed:


And here's the assembled machine:


He tried a couple of test runs with no fuel just to prove it was generating a plasma. But before he actually fired up the fusion reaction he moved it to a lab in the nuclear engineering building. Here's a picture of the deuterium plasma of the reactor in actual operation, generating neutrons:


This type of device is called a fusor and it is simple enough that several dozen very accomplished amateurs have been able to build one. Andrew Seltzman actually built his first fusor in high school. His new one is pretty sophisticated. It has a liquid cooled grid electrode and an ion injector. My hat is off to him and I hope he has a brilliant career as a physicist.

By the way, you'll never guess who invented the fusor. His name was Philo T. Farnsworth. You've probably never of him but I'm sure you've heard of something else he invented: television. Fusors are used as neutron generators but are hopelessly inefficient for power generation. The amount of power they consume is way more than they could ever generate. However, the fusor has a cousin that I've written about before that is more promising: the Polywell. I'm fascinated by this line of research and I hope it pans out. In the meantime, the pictures are pretty cool!