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!

Strange Behavior on Blogspot

I've noticed something strange about Blogspot. Have you seen the same thing? It's a bug in the word wrapping algorithm. This is the logic by which the software decides when to wrap to a new line within a single paragraph. It seems that the Blogspot word wrap algorithm doesn't want to start a new line with a quotation mark. To avoid this it will wrap too early and leave the previous line way too short. This is especially noticeable if the previous word is a long one. Let me see if I can create a couple of examples.

[If you follow this blog via a feed reader you will need to click the link and see this post in its original location on Geekspiel.]

With quotes:
The formatting method for quotations is incontrovertably "suboptimal" on Blogspot.

Without quotes:
The formatting method for quotations is incontrovertably suboptimal on Blogspot.

I kid you not; I did not insert the line break in the first example. Does anybody understand why this happens?

Toshiba A205-S5805 Specs

Looking for the specs on Toshiba's A205-S5805 laptop? You can find them here.

One of the many joys of operating a low volume blog in the backwaters of the Internet is setting up a hit counter and monitoring the traffic on your site. (I use StatCounter. Free and highly recommended.) It's interesting to see what pages are attracting attention and where the page hits are coming from. A couple of weeks ago I told you about buying a new budget Toshiba laptop for my eldest son to use at college. This particular model, evidently, is a configuration Toshiba put together just for Fry's Electronics and information on it is hard to find, even on Toshiba's web site. Not long after we bought the laptop Toshiba even removed what little info they had from their web site. As far as I can tell you can't find anything by following the links on their home page. However, like the grin of the Cheshire cat, they left behind a PDF of the spec sheet, which is the document I linked above.

What's this got to do with page hits? I've noticed several hits lately from desperate souls searching the Internet for information about this model. So, as a public service I have posted the above link, which I pulled from my browser history.

BTW, you can glean some interesting tidbits about Google's page rank algorithm from looking at the page hits. For one, if the keyword appears in the URL of the page it get ranked much higher than if it merely appears in the body of the page. This is why I titled this post as I did, so it will be found by the folks looking for the laptop specs. Another interesting tidbit is that a blog gets a temporary ratings boost (lasting less than 24 hours) when a new page is posted. I don't know if this works for blog hosts other than blogspot.com, which is owned by Google. Another surprise to me is that when I first created each of my blogs, after the initial temporary ratings boost it disappeared completely from the Google results until people began to visit it and link to it.

If you blog I highly recommend StatCounter. Maybe it only appeals to geeks. But I find it endlessly fascinating. My favorite feature is a Google map of the world with a pushpin showing the location of every recent hit. It never ceases to amaze me when one of my blogs gets hit from Moscow or Bangladesh or Antigua and Barbuda. Now, if any of those folks actually read anything before hitting the Back button is another matter entirely!

Computing in the Elder Daze

I was trading comments with a couple of twenty-somethings on a blog the other day and I got started thinking about emoticons. You know, the little sideways faces drawn with punctuation. :) It occurred to me that most twenty-somethings probably think they invented the dern things, and even find it amusing that an Old Guy like me would try to use them. They would be surprised to learn, I suspect, that emoticons have been around for about as long as they have! :0

Yes, my young friends, emoticons date back to the days of the Bulletin Board System (BBS). Do you even know what a BBS is? Now I shall engage in the favorite pastime of Old Guys. I shall reminisce.

Back in the late seventies, long before anyone outside of a university computer lab had ever heard of the Internet, personal computer owners began communicating with each other via modem using bulletin boards. Some generous soul would dedicate a phone line and a personal computer to the purpose, often paying for it out of their own pocket. That person would be called the SysOp (system operator). The BBS computer ran special software that allowed anyone with a computer and a modem to dial in and post messages to the board. Then someone else would dial in, read the messages that had been posted, and post their replies. It was exactly like an online forum today, except it ran on a single dedicated computer and (get this!) only one person could be connected at a time. (As personal computers became more powerful, some of the larger and more popular boards would have more than one phone line. But most only had one.)

In 1982 I bought an Apple II computer and began to write software for it for fun. I joined the Houston Area Apple Users Group. They ran a single phone line BBS for members. It was quite popular for several years. That meant that in the prime evening hours the phone line was almost continually busy. So here’s how it went. I would sit down at my computer in the evening, fire up my terminal emulator program and set up my modem to begin autodialing the BBS over and over. Eventually it would get a ring instead of a busy signal, and my machine would beep to let me know I was connected. I would log in and read all the messages everyone had posted since my last login. Then I would reply to several of them and disconnect. A while later I would start the autodialer again to get back on the BBS and see if anyone had replied to my messages.

My first modem was 300 baud. That meant it could only communicate at 30 characters per second. I could actually read the text as it scrolled by. Later I got a 1200 baud modem and I thought it was wonderfully fast. Too fast to read! Wow. For comparison, if you connect to the Internet today with a cable modem it’s roughly equivalent to something like 3,000,000 baud, give or take a couple of million.

I don’t actually recall when I first encountered emoticons. I’m not sure I ever saw them on a BBS. For sure, though, I remember them from the early nineties. The company I worked for first connected to the Internet around 1994 and I remember using emoticons in e-mail very early on. You gotta remember, it was actually us Old Guys that invented all this Internet stuff. I mean, Al Gore is an Old Guy, right? :)

El cheapo laptop

I must explain yesterday's outburst of rhyme. Over the weekend I was out shopping with Number One Son for an inexpensive laptop. We sent him off to college this year with a pretty powerful desktop PC, but he discovered it would often be helpful to take a laptop to class and the library, etc.

Dads gotta know how to embarrass teenage sons (it's part of the job description) so step one was to march into Best Buy and say to the clerk "Show me your cheapest laptop." Alas, we didn't find what we were looking for. We thought they carried the eeePC, but they only sell them online. We wanted to Look Before Buying, and their next cheapest laptop was $600. Exit, stage left.

We headed straight to Fry's as we are often wont to do together. (Number One Son is also a geek of some distinction.) Their weekend special was the Toshiba Satellite A205-S5805 for $398:

Yes, it's low end. Maybe even lowest end. Not quite a dog, but not snappy. However, $398 is a pretty good deal for a brand new laptop, especially one that only has to do word processing, surfing, and e-mail. I went home and ordered 2GB of RAM for $30 from frys.com just to stay in practice.

Happiness is a Fry's box on your front porch. Or in the trunk of your car.

Ode to Fry's

Oh wondrous to peruse your aisles,
More wondrous still to buy
Some trinket electronical
From thee, beloved Fry's.

Your ads, to wild enraptured flights
Of fancy bid me soar,
And beckon me to enter in
through your enchanted doors.

Your rebates have I often sought,
your sales have caught my eye,
I need another credit card
For thee, beloved Fry's.

Geek terrorists

This is disheartening:

Al Qaeda Seeks Tech Geeks to Run Multimedia Wing

It seems Al Qaeda has a media arm called al-Sahab which is now able to produce very slick propaganda films supporting their terrorist war against the West. They have been able to recruit a number of technically sophisticated (and presumably Western-educated) young geeks to amp up the technical quality of their productions.

Now if they could just hire some good special effects people maybe they wouldn't have to actually blow anybody up anymore.

Rise of the Machines

Will our digital creations always do our bidding? A cautionary tale...

http://fc01.deviantart.com/fs13/f/2007/077/2/e/Animator_vs__Animation_by_alanbecker.swf