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!