Getting My Robot Under Control – Part 2

Maxwell's performance during the movement cycling test improved a lot with the addition of the 'fullstop' subroutine. After executing 5 iterations of the movement cycle his longitudinal axis alignment was within 5 degrees of where it started, but the X, Y positioning of his center was still offset by roughly the same distance as the earlier tests. It was a huge improvement, no question, but there are still some underlying problems to deal with.

In order to sort out what might be happening, I propped Maxwell up on some spare batteries (they happened to be just the right height to get his wheels off the ground, and they were handy), drew a reference line on a piece of Post-It note, setup my digital camera to video the test, and then put him through his paces.

It became immediately obvious that the servo was creeping when it should have been motionless. A quick check showed that the other servo was exhibiting the same behavior, though the magnitude was considerably different. A little bit of internet surfing revealed that I should have zeroed the servos before I installed them into Maxwell's chassis....

Download 041128_servo_zero.wmv (100 kb)

Oh well, live and learn. Now I have two choices (at least two, there may be more.) I can disassemble the robot and zero the servos, then reassemble, or I can zero them in software. My immediate choice, perhaps wrong for the long term, is to zero them in the software. I suspect that the zero setting will change over time as the servo wears, or anytime I have to change a servo. My rationale is that if I build zero offsets into my code as defined constants, then it will be easy to change them universally later if that becomes necessary. Designing a program to determine the zero settings should be very straight forward, though I have some concerns about the possible effects of hysteresis on the zero settings.

Another 'learning' from my experience with Maxwell so far is that I will have to start labeling everything - i.e. putting small tags on the servos, cables, etc. and documenting it in my logs, photos, and videos. It's already become important to keep track of which servo is which. Later, as I start adding sensors and other circuitry, it will become even more important.

Read More

Getting My Robot Under Control

After I actually managed to get Maxwell, my first robot, to move around under his own power, I wanted to take a look at how repeatable his movements are. My earlier program was setup to have Maxwell move about one robot length forward; reverse back by the same amount; rotate 90 degrees CCW; then rotate 90 degrees CW. If Maxwell's servos were perfect he would end up in exactly the same place and orientation. It was obvious from watching him move around, that he was far, very far, from perfect.

In order to get a handle on what was happening, I put my camera tripod on top of my desk, and used my digital camera to video his movements. The camera is a Sony F-717 designed for straight photography. I wouldn't use it as a video camera replacement, but its quality turned out to be more than sufficient to handle this type of project.

To exaggerate any errors so that they would be easier to analyze, I rewrote the program so that Maxwell repeats the same move sequence five times in a row. Video from several test runs showed that although the robot was making linear moves in a straight line, it was definitely having problems maintaining a repeatable course. 

This chart shows the robot's original position in red, and it's final position after five repetitions in black. Each time it went through the cycle its ending position was offset by a small factor on an X, Y basis, and by a large factor rotationally. By the time it had completed the 5 move cycles, Maxwell's longitudinal axis had rotated by approximately 135 degrees. There was also some small X and Y displacement of his center - but I'm going to ignore that for the moment until I get the bigger problems sorted out. It may turn out to be a side effect, and I don't want to waste a lot of time chasing that particular rabbit until I have to.

Examining the video in more detail it appeared that the biggest single problem was overshooting due to inertia. Once the robot was moving, it tended to continue moving even after the program had stopped telling the servos to move. The robot's momentum was hard to slow down purely by the friction generated within the servos.

To test this hypothesis, the program was modified to call the 'fullstop' subroutine after each move. The Fullstop subroutine sends series of PULSOUT commands to the servos with a value of 750, which should be zero rotation. The modification appears to correct roughly 80-90% of the problem, but there are obviously other contributing factors. I'll have to dig deeper.

Download servo_test_0004.wmv (video - 300 kb.)

Read More

Maxwell Lives!

Or more precisely, Maxwell communicates and walks!

It took about an hour of cable switching and software diddling, but I finally managed to get my desktop computer talking to Maxwell via the serial cable. I could see the serial port at the operating system level, but the Parallax software didn't seem to see it. I decided to brute force it by manually entering port numbers until it saw the Basic Stamp. I entered port 1 as my first input, and like magic everything started working.

From that point on every thing went very smoothly. I built a couple of simple circuits on the BOE breadboard, just to make sure that things were working, then tried to hook up the Parallax servo. At first the servo plug wouldn't fit into the socket. On close inspection I found that there was still a small plastic stub on the servo connector, probably left from the manufacturing process. A little plastic trimming, and the plug went into the socket like a breeze.

I started with the servotest program exactly as it is described in the manual, and it worked fine - which was very encouraging. Then I switched over to the Rogue Robot supplied servos that will be used to drive the wheels. Of course I proceeded very carefully - testing each servo by itself before I developed a confidence level that it was all going to work out okay.

A few minutes later I had both of the wheels going - first just spinning in the air, then later walking on the ground and/or dining table. From that point it was a piece of cake to get Maxwell moving around the desktop. First just one wheel, then both moving together - forward, backward, clockwise, counter clockwise.

Download Maxwell001.wmv (200k)

Read More

One Step Forward, Two Steps Back…

Some days you get the bear, and some days the bear gets you. Earlier this week I made great progress with Maxwell and it looked like everything was coming together. The initial unpacking, inventorying, and assembly had very few problems.Then I hit the wall.

My initial thought was to do all of Maxwell's software development on my desktop system upstairs. It has about 180 gigabytes of networked storage that I can access from my laptop downstairs, and is relatively fast. Like all of my current PCs, it runs the Japanese versions of Windows, and, since it's a little over three years old, it's running Windows 2000 instead of XP. It's a Sony Vaio and includes a lot of Vaio specific bells and whistles, so I'm very hesitant to upgrade the operating system, as much as I would like to do it.

Everything should have worked fine, but...

In order to talk to the Parallax BOE (Maxwell's brain), I tried using an old USB to serial adapter cable that I had used years ago to interface to a serial printer I used to own. My PC recognized the new hardware/cable, but for some reason didn't have the driver installed. It turns out that the original manufacturer of my adapter cable had been taken over by Xircom, and then Xircom was bought out by Intel... After a lot of searching I managed to locate what appeared to be the right Windows 2000 driver, but when I tried to install it my system kept giving me the same old error message.

Then I tried a brand new adapter cable that I purchased from a PC parts shop near the office. Same problem even with the new adapter and a new driver down-loaded from their website. So, I decided to move Maxwell and the rest of the stuff downstairs and try again using my laptop.

This was deja vu all over again. My laptop runs Windows XP, but didn't like the adapter cable any more than it's desktop cousin upstairs did. I tried various permutations and combinations, and only managed to raise my blood pressure and frustration. Finally, about 1:00 am in the morning, I shut everything down and decided not to work on it again until I got some sleep and could tackle the problem with a clear head.

Last night I didn't have any free time to dig into the connection problem, but I did manage to quickly pull my desktop system away from the wall and confirm that it has a built-in RS-232 port. Tonight or tomorrow I'll try connecting Maxwell up that way. It's not the optimum approach since it means that only my desktop system will be able to talk to Maxwell, but if it works at least it will get Maxwell up and running. Sooner or later I'll have to fix the core problem though if I want to communicate with Maxwell and his children (yet to be conceived) outside of my home office. 

Read More

Initial Robot Assembly

Maxwell's initial assembly started Thursday evening. I didn't have much time to work on it - only about an hour - but I wanted to at least begin the process.

Maxwell's base is the Rogue Robotics Rogue Blue 2-level that I purchased from Hobby Engineering in Northern California. It came packaged in a series of sealed plastic bags containing all the parts plus a minimal parts list. A quick inventory of the kit confirmed that everything was there - though I was surprised that the kit didn't contain the battery holder that was shown in the website photo. The holder isn't listed on the kit parts list, so I'm assuming that it has to be obtained separately. Kind of strange since the kit does include both mounting hardware for the non-existent holder and velcro.

In the short term it isn't a big problem since Maxwell will be tethered to my laptop as I get familar with programing him. Hopefully before I'm ready to let him start exploring on his own, I'll have a chance to stop in Akihabara and buy a battery holder.

The biggest problem 'out of the box' was that the Rogue Robot instruction manuals are not included, they just point you to their website with what is supposed to be the right url. Unfortunately their website organization has changed since this particular kit shipped, so the url didn't work at all. It took me a few extra minutes to search their website and determine the correct url.

Once I found the right 'manual' on their site, the assembly went quickly.

Two modified servos act as the wheel motors.

The ground clearance is minimal. There are two teflon buttons mounted at either end of the bottom base with a double sided sticky pad. I'm not particularly happy with this approach, but it will have to do until I have time to re-engineer it. Maxwell is going to be able to run around on a flat surface pretty well, but any bumps or depressions are likely to stop him in his tracks.

The tires appear to be a fairly stiff foam rubber that should provide good traction. The wheel slips easily onto the servo and is held in place by a long screw.

This is a closeup of the wheel surface. Close inspection of the wheel and mount showed the presence of tiny black particles - apparently rubbings from the wheel tires.

Maxwell's 'brain' is the Parallax Board of Education (BOE). The plastic bag it comes in had a detailed sticker covering the jumper selections, power considerations, and other details. Just in case, I took this photo of the sticker before I opened the package.

The back of the BOE board is silk screened with tech support contact information - email and phone; the power switch settings; and a breif ad for the Parallax education courses.

The BOE mounts on top of the base using hardware supplied with the kit.

I still have a lot of work to do before Maxwell starts moving around, but at least he's starting to look like a robot.

Our dog Austin paying close attention to Maxwell's construction. He probably thinks it's something to eat...

Read More

Mechanical Design – Some Thoughts

It's way, way too early in the process to start thinking about some of the design details. I haven't even opened all the kit packages yet - I've been too busy cleaning up and organizing my home office space. That should be finished in the next few days, and then I can start familarizing myself with the various components and assemblies. In all probability it will be weeks before I actually have Maxwell to the point that he can start to take his first steps. My best guess is that it will be close to Christmas when I start to get seriously involved with the issue of sensing the outside world - plenty of time.

Still, as I think about what Maxwell will eventually look like and what he will need in the way of sensors and displays, I know that my design priorities should include factors like:

  • design flexibility: design flexibility in from the beginning to avoid massive redesign and lost time later in the process
  • adjustability: sensor angles and component positioning may need to be changed unexpectedly
  • solid, stable: needs to withstand being transported and handled (manhandled?) without needed extensive readjustment or alignment
  • clean, neat, well packaged: professional looking design; no rats nests; clean lines; nothing I would be ashamed to post a photo of on the internet

Sensor mounting
For example, on the bus I was thinking about sensor mounting, LED and/or IR sensors specifically since I think that Maxwell will need a few no matter what I want him to eventually do. I've seen a lot of different approaches for mounting on various micromouse sites. While all of them seem functional, a lot of them look very juryrigged and fragile. I can easily imagine how difficult it is for them to produce consistent, repeatable results. Of course, some juryrigging is always necessary when you prototype anything.

Some of them involve using hot melt glue, bending sheet metal brackets, or the proverbial bailing wire and bubble gum. The bent sheet metal poses some issues. If the metal is soft enough to work with, it's also soft enough to bend when you don't want it too - and always at the worst possible time. If it's stiffer, then it becomes hard to adjust to align the sensors.

One approach that really appeals to me, at least at this point in the game, is to mount the sensors as modules on a length of threaded rod stock. Each module would include an emitter and a sensor. The relative weight of the sensors is small, and as long as the rod length is fairly short it should be stiff enough to hold them in position without much vibration or misalignment. The sensor positioning can be easily varied along the length of the rod, and it's vertical angle relative to the horizon should also be easy to adjust. At least that's my theory at this point. We'll see how it plays out.

Read More


I ordered the basic parts/kit for "Maxwell" from Hobby Engineering in California and expected it to take quite a while to find it's way here through the international postal network. Happily, it didn't take anywhere near as long as I had expected. We were gone over the weekend, and when we came back and sorted through the mail we found a note that the shipment was waiting at the main post office.

Unfortunately, since I didn't expect it yet, I haven't cleaned up my home office workspace... That will have to take precedence over playing with studying everything in detail. The most I accomplish at this point was to unpack and inventory everything.

The order consisted of three basic items - the robot base (Rogue Blue Base), the micro-controller (Basic Stamp 2 Discovery Kit), and a wall wart for power. Everything was there and accounted for - at least as far as the three items were concerned. Later, when I have time to dig into each package, I'll verify their contents as well, and hopefully take photos to document everything.

The shipping container consisted of the normal brown cardboard box filled with blue-green foam peanuts. The overall dimensions of the box were about 3X the size needed for the contents, but was probably selected because the box for the micro-controller kit just fit nicely inside. The shipping clerk put the micro-controller kit box in the bottom of the shipping box, then put the other two pieces on top of it, and filled the open volume with foam peanuts. From a shipping perspective, this leaves the contents open to impact damage since there is no cushioning from the foam. Fortunately it appears that everything arrived intact and undamaged.

After work this evening I'll probably stop by the local computer store and pick up a USB to RS232 cable. The micro-controller kit only came with a RS232 connector at the time that I placed my order, and my laptop doesn't have an RS232 port. I did notice that Hobby Engineering has since added a USB version of the kit with slightly different pricing.

So far, and keeping in mind that it's very early in the process, I'm very pleased with the response and support from the staff at Hobby Engineering. I'm really looking forward to visiting their brick and mortar store in person late next month.

Read More

Maxwell – A Robot's Genesis

"Show me how it doos."
James Clerk Maxwell at the age of 3

I've always had a fondness for James Clerk Maxwell, the famous mathematician, and I've always found it difficult to come up with meaningful names for my projects, so I decided to name my new robot project "Maxwell." Given Maxwell's inate curiousity about the world and how it works, I'm sure he wouldn't mind lending his name to a brand new robot soon to start discovering the world around it.

Doing some initial thinking about Maxwell (the robot that is, not James Clerk), I wanted to map out some discrete layers or functional levels. The exact purpose behind Maxwell isn't clear yet - and perhaps it never will be. But I'm willing to embark on the journey just for the sake of the journey itself and the learning that will come along the way. Still, a little advance planning never hurt, as long as it doesn't get in the way of having fun.

So, given that I don't have a clue what I really expect Maxwell to do, how can I go about doing any planning? I decided to set totally aside the "final outcome" for now, and focus on the basic "what" instead.

Initially I don't even want the "how" to be a factor. If I start taking the "how" into consideration at this point its constraints will automatically build limitations and restrictions into Maxwell that I might not be happy with later. For example, if I decide at this early stage that I want to use an IR distance sensor, then every decision about distance sensing after that becomes centered around the strengths and weaknesses of that particular approach. Over the years I've found it much more advantageous to approach problems from the other direction. In this case I would determine what I want to sense - say distance - then look at all the possible alternatives, narrow them down to about three or four practical approaches, then figure out what is the best solution for what I need to accomplish. I might still end up using the same IR distance sensor, or I might use something completely different.

A good example of this is Steve Hassenplug's Legway robot. Steve wanted to try his hand at a Lego version of the famous Segway. To solve the two wheel balancing problem at first he looked at gyroscopes, accelerometers, and other solutions. But, by focusing on the 'what' instead of the 'how', he realized that he could simply measure the distance between the ground and two optical sensors mounted on opposite sides of his robot. Instead of taking weeks to design and debug, Steve was able to put together a working version in one evening.

A good place to start is to group Maxwell's basic functions into groups. No matter what his final objective is, he will need to sense the world around him, move somehow, and communicate. Otherwise he might as well be an expensive brick.

Within each functional group I've listed the subfunctions that immediately came to mind in the rough order that I might go about implementing them. This, like all things in life, will change over time.

Sense - Proximity sensing will be important for Maxwell to avoid running into things or crashing off the edge of tables or stairs. It might also play a role if he wants to be a soccer player when he grows up (don't laugh - the folks at the San Jose robot club are working on soccer robots.) Being able to sense light and sound could also be of great practical importance. I'm not a big fan of line following robots, but who knows - I might want Maxwell to do that kind of thing at some point in his development. Sensing position, especially absolute position in some world coordinate system could present some major challenges, but I don't want to automatically rule it out at this early stage.

Move - Maxwell should be mobile. He should be capable of moving around under his own power - at least as long as the charge on his batteries holds out. And it would be useful if he could grip or interact with other objects physically in some fashion.

Communicate - Maxwell should be able to communicate in someway with the outside world - blinking leds, beeps, whistles, perhaps even with a voice at some point. That type of functionality is great for monitoring and debugging, and it adds a great deal to the overall experience of playing with a robot. Being able to feed back his data and observations to another computer - say my laptop PC - would be great.

I want to use this as a basic structure that I can build on as Maxwell evolves. I tend to believe that as Maxwell becomes more and more complex some functionality may need to be off loaded to one or more co-processors. For example - many simple 'first' robots use the processor/controller chip to directly control the drive servo/motors. This usually entails putting the processor into a short delay loop to kill time during each one of the moves. A simple robot doesn't have to deal with many inputs, and doesn't have to make quick, on-the-fly decisions. On the other hand, if Maxwell wanted to be a competitive robot soccer player, he would have quickly sense the world around him, track the ball, perhaps avoid the opposition, and be fast on his feet (wheels.) There wouldn't be anytime to waste going around in delay loops just to control a servo motor pulse width. If and when Maxwell gets to that level, I will have to implement some type of co-processor scheme, and I know I won't want to be faced with redesigning everything from scratch. Keeping Maxwell's functional grouping in mind as I develop the hardware and software may (hopefully) make expansion and change much easier later on.

At least that's what I hope...

Read More