Robot Redux

After many months of inactivity, Alan and I have restarted the robot project. If you recall, we wanted to build a robot that would balance on two wheels and could be controlled by a remote. Last time we succeeded in building a robot that could travel about horizontally on three wheels (actually two wheels and a caster). But it didn't have enough power to do a wheelie. In our attempts to increase the power by increasing the voltage of the battery pack I think we managed to burn out one of the motors. It began to lose power so that the robot could not drive straight. Since one goal of the project was to see how cheaply we could build such a robot, the motors we used in Rev 1 were very cheap. This time around we decided to rebuild the original design with better motors. Below is a picture of the new Rev 2. Notice how small the motors are! They are actually more powerful than the last ones. I put a quarter on top of the right motor to give you a sense of scale:

And here is a picture of the internals showing all the breadboard wiring. In this picture, the robot is plugged into my PC via the USB port. That's how we download new software and upload performance data:

Here's a close-up of some of the breadboard wiring:

Here's a video of Rev 2 showing it being successfully driven around our kitchen right after we finished building it. We initially set the power level at only 25% of full throttle to make sure we didn't burn anything out right away, so the vehicle can move faster than this, but not a lot faster:



Even though we bought more powerful motors, this version is still nowhere near powerful enough to do a wheelie. Not even close. My goal for this round is to experiment with the balancing logic, even if the vehicle has to be manually helped to an upright position.

The big issue is still whether we can balance at all using this design. Because we were going for a cheap design, the current vehicle has no encoders to determine wheel movement and no gyro to determine rotation rate. The only sensor is an inexpensive 3 axis accelerometer (the MMA7260Q). This is a configuration that conventional wisdom says cannot be made to balance successfully. We will probably succeed only in proving the conventional wisdom, but I want to give it a go, anyway.

After these photos were taken, last week Alan wired up the accelerometer to the Arduino microprocessor board. Unfortunately, I forgot to add a line in the software to set the ADC circuit to the right mode so I burned out that part of the microprocessor. The rest of it still works, but it cannot do any analog-to-digital conversions. So I couldn't start work on the balancing software. I ordered a replacement chip which arrived this week. It's going to be a bit of a pain for Alan, because he will have to practically disassemble the thing to replace the CPU. Hopefully this weekend we can do the repair and we'll be back in business.

Post Mortem - Robot Rev 1

It's been a long time since I posted our progress on the self-balancing robot project. As you may have guessed, that's because it's been a long time since we worked on it. Our first attempt didn't go all that well, and we both got busy with other projects. Recently Alan and I have been wanting to jump back in and try again. This report will describe what we learned from our first attempt.

As you may recall, last time I reported that the robot was able to roll around and respond to commands from the remote control. We had two problems, however. The first was that one wheel started turning immediately after we switched on the power. It would continue to turn for a couple of seconds until the Arduino microprocessor finished booting. Our proposed fix worked well. We installed a couple of pull down resistors to hold the control line low until the computer began driving the signal low. (They were hard to add, though, because the finished breadboard wiring was very messy. That's another area we want to improve next time.)

There was still a question about how the motors were drawing any current when the USB was connected to the Arduino but the battery wasn't. After some discussions on the Arduino message board, it was decided that indeed there would be some voltage on the VIN pin if you applied power to the 5V pin. So that mystery was solved. With all of that, we now had a dandy little remote control car.

However, we were a long way from a self balancing robot. The second problem was more fundamental. The motors clearly didn't have enough speed and/or torque for the robot to do a "wheelie". If it couldn't raise itself up on two wheels to start with, there was no way it was going to balance on two wheels. We tried increasing the voltage by switching to 8 AAA batteries instead of 6 AAs. But it was nowhere near enough. On top of that, after we had made a number of attempts to fix the problem the motors began to turn even more slowly. One wheel, in particular, was turning very slowly. We checked the voltage across the motor leads and that wasn't the problem. Clearly the motor itself was failing. So the bottom line is we are going to need new, more powerful motors. The ripple effect of that change will result in several more design changes. For instance, more powerful motors will draw more current than the current H-bridge can handle. They also may not fit in the same location on the chassis. At that point we realized we were going to need a Rev 2 on the whole design.

It's not all bad news, however. Here are the things that went well:

• Using the DVD remote control worked great!
• Programming the Arduino was easy and fun.
• The motor control circuit worked well once we added the extra pull down resistors.
• The overall physical design worked well, including the idea of using a plastic project box as the chassis.

So we actually managed to build a remote controlled car from scratch. That in itself was fun and rewarding. To close, I finally have a few pictures to post so you can see what we built.

Here is the robot all assembled. Do you like the racing stripes? We were experimenting with AAs versus AAAs, so we had rubber bands holding the battery packs on:



This is a closer shot of the front end showing the roller that serves as the front wheel (there's one on each side) as well as the IR remote control receiver and an LED to indicate system status:



And here is a closer shot of the back end. It shows the power switch as well as the USB port used to program the Arduino. The small black button is a reset button. We never needed it because the software worked great:

The robot is rolling (literally)

Last weekend Alan finished assembly of the self-balancing robot, Rev 1. This first version isn't supposed to balance on two wheels yet, just roll around on three wheels. It works! Well, sort of. We have some debugging to do, and some design changes are in the offing. I still have no pictures to post, for which I apologize. Alan has the camera and I haven't had a chance to upload them.

It was pretty exciting when we first powered it up. Alan plugged the Arduino into the USB cable so we could download the software, and immediately one of the two wheels started turning! It didn't stop until the control program was finished downloading and booted up.

Now, mind you, I was pretty shocked because we hadn't connected the batteries yet, and the motors are supposed to be getting their drive current from the batteries. Somehow they were getting 5V power from the USB via the Arduino. I was concerned because the Arduino can only source 40mA from each pin and if we were drawing too much current it might be damaged. We discovered, though, that if we go ahead and unplug the USB and run from the batteries, the wheel still turns a couple of seconds, but then everything seems to work after it boots. We can use the IR remote control to drive it around on the floor. Pretty cool!

So now I have several questions to investigate:

1. How can the motor draw power from the USB through the Arduino?
2. Why is it only one motor that turns at power up?
3. How can I fix it?

Here's the circuit diagram (click for a larger version):

The H-bridge is actually an SN754410 although the diagram says L293E.

I think we can probably keep the wheels from turning at power on by adding pull down resisters to the enable lines on the H-bridge. I'm guessing the enable pin voltage is basically drifting until the Arduino drives it low in the setup routine. But I really don't understand how the power is getting to the motor. I hope to get some help from the Arduino user forum.

Aside from the mystery of the spinning wheel we have one major design issue. The motors I selected have plenty of torque, but not nearly enough speed, for the robot to lift itself to a vertical position. We are looking at ways we can address this short of simply buying different motors. The first thing we want to try is to get a little more speed out of the existing motors by upping the voltage. We intend to replace the six AA NiMH batteries with eight AAA NiMH batteries. This also makes the robot lighter. Eight cells will give us a nominal 9.6V, which after the 1.4V drop in the H-bridge becomes 8.2V. This is substantially higher than the net 5.8V we have now. The motors are supposedly rated at 12V, although I'm pretty sure they would overheat quickly if driven continuously at this voltage. But it will only take a fraction of a second for it to raise itself to vertical.

We'll try the pull down resisters this weekend, but we're waiting for parts to convert from AA to AAA batteries.

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!

Geek Offroading

Did you see this video? Carnegie Mellon is developing autonomous vehicles for the military. It's called the Crusher. There's no human on board. This thing drives itself and can climb four foot walls. You can see more videos on CMU's web site.

Gotta love DARPA. They have all the cool toys, don't they?