ROBOTS DREAMS

Modeling Maxwell

I put together a simple 3–D model of Maxwell to help visualize and play around with future modifications – before I actually invest the time and $$$ to implement them. Using SketchUp, it was easy to build a dimensionally accurate 3–D model, and to rotate it for viewing from any angle.

Maxwell is based on the Blue Base from Rogue Robotics, and has a Parallax Board of Education (BOE) controller. As I have time, over the next week or so, I’ll flesh out the model adding the controller and other details.

Controlling Your Robot: IR Remote Control Kit

I wanted to add a simple remote control to Maxwell. Nothing fancy – just an IR link to control him forward, backward, right, left, and stop. While I was visiting the Hobby Engineering store in California I happened across the “Kit 92 IR Remote Control & Decoder IC” by Kitsrus.com (as in “Kits are us”, not “Kits Russia”), and since it was only $12.95 I picked one up. 

The kit comes in a thin walled plastic box that houses the remote control, components, and an instruction sheet. Their site includes a pdf copy of the instruction sheet.

Here’s the label on the box. Note the “sample circuit supplied” comment. 

The components include the decoder chip, a 12 Mhz resonator, three capacitors, an LED, four resistors, a diode, and the IR receiver module. There is no circuit board. The expectation is that you will breadboard the circuit using the components supplied, and then incorporate your proven circuit into a larger circuit design.

The decoder chip is a preprogrammed Atmel controller. 

 The 3 pin IR module is a Waitrony PIC1018SCL. They provide a link to the Waitrony datasheet (pdf.)

There is also a nice resistor color code chart included in the kit. This was quite handy since I always have trouble remembering the “Bad Boys R… Our Young Girls, But Violet . . .” rhyme.

The remote control unit is pretty cheap, and the buttons feel it. Still, what do you expect for $12.95?

The emitter end of the remote control. I definitely plan on testing the range and pattern before I let Maxwell run around free on the floor.

 The remote control takes two AAA batteries (batteries not included.)

The pins on the decoder chip were pushed through foil and then into plastic. That’s okay, I guess, but I always worry about static electricity zapping my electronics.

The circuit was very simple and straight forward to breadboard. The IR detector is in the upper right, the decoder chip in the middle, and a LED to give a visual indication is at the bottom. For the initial testing I only hooked up one output of the decoder. The kit only provides you with the components for one output, assuming that you will be linking the outputs directly into your robot’s controller inputs. 

The instructions show a pinout table for the decoder chip that’s easy to follow since it’s laid out in the same order as the chip pins.

I only found one significant error – a typo that mislabels pin 9 as pin 8. 

URLs are listed for their website, the IR receiver module datasheet, and to contact them via email. They offer to sell you any extra components, but only sell the complete kits via their dealers and distributors, like Hobby Engineering. One concern I have is the statement that “The code inside the decoder IC is locked and is not available.”  I can totally understand and appreciate their position. I would probably do the same thing. Still, as a hobbyist, I want to take things apart and modify them. For example, their decoder’s outputs are individual lines. That requires me to either use a lot of input pins on my robot’s controller, or add some additional circuitry to compress/encode the signals. I would rather just modify the code inside the decoder so that it outputs the codes I want directly. I have to give it more thought, but I suspect I may end up doing a version of the code using a PIC chip.

 The instructions are a single sheet, printed on both sides. The front side includes the component list, pinouts, circuit description, and supporting background information.

The back side of the instruction sheet includes a sample test circuit. Note all the LED’s and current limiting resistors tied to the outputs. This is purely for demonstration and test purposes – not something you would actually use verbatim in your robot design.

Conclusion: The K92 IR Remote Control & Decoder IC kit is well thought out, and does everything as advertised. It was good for testing and prototyping. If your needs aren’t very complex or demanding, it may work well as a part of your design.

The Ultimate Solution?

After going back and forth through several different iterations trying to get Maxwell to move consistently and predictably, it's time to take a step back from the problem and see if there isn't a better approach.

Basically, all we want is for the robot to execute a few simple movements.

It should be able to move in a straight line forwards and backwards. It should be able to rotate about its center clockwise or counterclockwise for a specified angle. It should be able to pivot around either wheel through a specified angle.

If it can perform those basic moves, then more complex moves can be executed by combining or extending the basic moves. For example, by interleaving commands for a turn and a linear move, we can have it follow the path in the figure above.

In theory, it seems very simple, but in practice it's turned out to be frustratingly difficult....

Perhaps the problem stems from the fact that everything is running 'open loop' - without any active feedback mechanism. The previous attempts have tried to deal with servo motor linearity, and balancing of the speed of the two drive servos. While it may be possible to succeed using that approach, it runs a significant risk of being totally hardware dependent. If the characteristics of one servo changes, or if one of them needs to be replaced, then the program constants would have to be retested and adjusted accordingly.

An alternative approach would be to implement wheel encoders to measure the actual rotation of each wheel. This is roughly equivalent to the technique used to measure the servo linearity, only the measurement would be done real-time, while the robot is moving.

More importantly, the level of abstraction changes - hopefully for the better. With wheel encoders the control program focuses its attention on moving each wheel by a given number of degrees or rotations. Ignoring the problem of slipping for the moment, each wheel movement will result in the robot moving by a predictable amount - independent of the servo speed. In effect, it would longer care what the servo linearity happens to be. It would simply send commands to increase, maintain, or decrease the servo speed to acheive the wheel rotation it needs. Servo motors could be changed without the need for recalibration. Complex movements should be simplier to implement. Moving in a straight line becomes a problem in matching the actual rotation if each wheel - as reported by the encoders. The distance calculations should be much more straight forward since they should be directly proportional to encoder steps (ignoring slippage for the moment.) And all of this should be fairly independent of the servo motor speeds.

So, it looks like it's time to seriously consider implementing wheel encoders for Maxwell. The good news is that the same strategy should have a lot of application to future projects. None of the learning will be wasted - quite the opposite.

Does Servo Linearity Really Matter?

It's been a real struggle to get Maxwell to move in a repeatable fashion, so obviously there is something going on at a core level that I haven't fully understood yet. Commands that should cause him to move straight forward or backward end up with him drifting off in one direction or the other. Turns seem to be the most challenging. Even more puzzling, the commands should be symmetric and reversible. A 90 degree clockwise turn followed by a 90 degree counterclockwise turn should bring him back to the starting point. Unfortunately, it doesn't.  And any regular path, repeated over and over again, quickly starts to resemble a Spirograph drawing.

My approach has been to test the linearity of the servo motors that drive the robot's wheels, assuming that I would be able to apply program compensation factors. Earlier posts went into detail about the test fixture and program design to automatically determine the linearity of each servo. The actual Excel charts don't show up very well on a web page (at least I haven't figured out how to make them look good yet), so here's a conceptual chart based on the actual test data:

While at first glance it appears that the servos are fairly linear over a large part of the range, but, looks can be deceiving. The best linearity is in the range of PULSOUT() values from 640 to 860 which yields about 25 rpm. With the robot's current 3" wheels, 25 rpm corresponds to 1.25 ft/sec (38.1 cm/sec.) There is a noticeable divergence between the two curves, in addition to a zero offset. And, even within the 25 rpm range, the curves have an "S" shape.

There's another, more significant, factor that somehow I managed to overlook:

In order for the robot to move 'forward' the two servos have to move in opposite directions. One has to move clockwise while the other rotates counter clockwise. This is due to the physical mounting of the servos, and has to be taken into consideration for all movement routines. That means that the two matching values for any linear movement are going to be on opposite sides of the curves.

There is also a slight but nevertheless significant zero offset for each servo. The zero offsets, by themselves, are easy to adjust for. But, in thinking through the implications of the zero offsets, I started to wonder if the issue of servo linearity could be skirted completely by another approach to the problem.

• Is it nescessary, or even useful, to be able to continously adjust the robot's speed?
• Isn't no-motion just a special case of motion?
• If the zero offsets can be set by simple values, why not do the same thing with all motion?
• Would an approach with discrete speed steps be practical?
• Would a discrete step approach result in repeatable and reversible turns?

I'm currently considering a simple lookup table with entries for FAST, MEDIUM, SLOW, and ZERO for each servo in each direction. The initial table values will come from the test data that's already been collected, and will then be verified by actual testing.

Measuring Servo Linearity - Test Jig

I wish I could say that I spent a lot of time studying component data sheets and weighing the trade offs. But, it's just not true. My approach was much simpler and more straight forward. While checking the bins at a shop in the Akihabara electronics district I bought several different optical sensors primarily because they were cheap and I wanted to experiment with them.

One of the sensors I bought was the Toshiba TLP800A photo-interrupter infrared LED and photo-transistor. The LED and photo-transistor are housed in a common package with a 3 mm slit between them. In normal use a shutter, usually part of a small diameter disk, rotates through the gap interrupting the light from the LED

Using the TLP800A it was surprisingly easy to breadboard a test jig and circuit. The cutouts in Maxwell's chassis extend slightly past the outside edge of the wheels. Heavy tape was used to secure the sensor in position, and to fashion a simple shutter. The shutter was fastened to the wheel using two push pins (the wheels are black foam). A DVM monitored the output signal while the wheel was rotated manually to adjust the shutter to sensor positioning. Once the two were properly aligned, the photo-transistor output signal was connected to the micro controller and the test program ran automatically.

The test program was run several times on each servo and the results were extremely consistent - a significant improvement over the previous manual method. Timing data was collected for PULSOUT values ranging from 500 to 1000. The test program writes the results of every cycle to the DEBUG console in an Excel friendly CSV format. This makes the test data extremely easy to chart and analyze.

Scatter vs. Reflection - IR Sensors - Robotics

It looks like I will have to do some serious testing with IR sensors to determine their sensitivity to scatter as well as reflection. For example, the Parallax BOE-BOT manual has a section that explains how to detect drop offs like the edge of a table using IR sensors. They show this figure-

If we were dealing strictly with light rays the light would be reflected off the surface at the same angle that it impacted it, and no light would bounce back to be sensed. However, no surface is a perfect reflector, not even a mirror, so some of the light is scattered and a part of it does end up traveling back to be detected by the sensor.

I thought, incorrectly, that the scattered light would be small enough that it would be very hard to detect and perhaps even lost in the noise. What I didn't know was that the IR emitters are pulsed at 38.5k and the sensors are looking for that frequency. This helps deal with interference and noise issues, and also implies that the back scattered light is easier to detect.

In a controlled environment, like the micromouse maze, the light patterns, especially the back scatter patterns, should be fairly repeatable and predictable. It may turn out that some experimentation with the sensors will yield a method to determine the wall status for the next cell before entry.

Maxwell - Robot Servo Linearity Testing

When I visited Akihabara last Saturday with Inoue-san, I picked up several different types of LEDs and phototransistors to experiment with. The initial challenge was to hack together a way for Maxwell to test the linearity of his servo motors. Later the knowledge gained will be useful in developing an encoder strategy and for other applications.

The first approach used a discrete LED and a photodiode. It was workable, but maintaining the physical positioning of the components and aligning them with the servo wheel marking turned out to be the big challenge. The second approach used a packaged LED/phototransistor pair.A small opaque 'flag' was fabricated from tape and attached to the side of the wheel, then trimmed so that it passed through the center of the detector.

A simple circuit was breadboarded on Maxwell's BOE -

Note: D1 and Q1 share the same packaging with a small slot for the flag to pass between them interrupting the optical path.

The circuit output signal was connected to IN3 on the Basic Stamp controller. A test program was written and debugged to cycle through a range of PULSOUT values measuring the number of commands required to rotate the servo motor 360 degrees. Since the flag position was unknown at the beginning of each cycle, the program had to reposition it automatically. An unexpected benefit of this approach was that the servo was already in motion at the start of each measurement. During the previous tests the servo was always at rest at the start of each test cycle. This meant that the servo had to overcome some initial inertia and accelerate to the test speed during the test itself. The impact would be minor for low rotational speeds, but would rapidly impact the overall measurements as the speed increased. Having the servo already rotating at the speed under test is a more accurate test.

At the completion of each cycle, the program outputs the measurements via the DEBUG console where they can be copied and moved to Excel for analysis. The analysis process can be simplified quite a bit if the program outputs the data in a pre-processed form. For example, if it writes the data to the DEBUG console in comma delimited format, it's easy to just cut and paste into Excel without having to reformat and/or edit the data.

This chart shows the test results for Maxwell's right servo motor when tested with PULSOUT values ranging from 550 to 740 in increments of 5 -

The automated testing provides much more consistent results as well as allowing for improved measurement granularity. For example, the earlier tests were run manually with test increments of 10. The initial automated test increment was 5, but could be as low as 1. One concern is that for fast rotational speeds the number of PULSOUT commands sent is relatively small - in the range of 70 or so per 360 degree rotation. To improve the measurement granularity the program can be modified to measure the number of commands required for mulitple rotations.

The biggest single advantage? Simple - I can start the testing, then go do something else. I don't have to babysit it. And, it allows me to run longer, more extensive testing than the manual approach.

Maxwell - Robot Servo Linearity

In thinking through the servo motor programing strategy I realized that the servos may be non-linear. Research (via Google, of course) uncovered a simple Basic Stamp test program in the BOE-BOT guide to robotics on the Parallax website. Maxwell isn't a BOE-BOT, but is close enough that the programs run with very few modifications.

The basic approach is to put the controller into a loop where the timing is known then measure how far the servo rotates during the loop execution, then multiply the rotation by an adjustment factor. In this particular case the program rotates the servo for six seconds while the rotations are counted. The result is then muliplied by a factor of 10 to derive the RPM figure. Their recommendation was to use PULSOUT commands ranging between 650 to 850, but I decided to take a couple of additional measurements extending the range to see how quickly it would become non-linear.

This chart shows the test data for one of Maxwell's servos. The vertical axis represents the PULSOUT parameter passed to the servo while the horizontal axis charts the resulting RPM. It's easy to see that the servo zero is slightly offset from the theoretical null position. If it was zero'ed perfectly the curve would in intersect the origin at (0,750). The offset is relatively minor - small enough that a constant in the control program can adjust for it. The servo is relatively linear from 650 to 850, but rapidly becomes non-linear outside of that range.

The next steps are to -

1. Run the same linearity test on the left servo
2. Compare the linearity and zero offsets between the two
3. Develop a more sophisticated test program to automatically collect the data with more precision and granularity

#1 will happen some time over the next few days. My schedule is pretty full, but the test only takes about 30 minutes to run per servo, so I can fit it in somehow.

#2 involves some analysis of the data in Excel and may be as simple as setting up a couple of additional data columns that add offsets to the collected data then chart the results.

#3 is simple in principle, but may end up presenting some difficult and interesting challenges. My initial thought is to breadboard a sensor similar to those used for line tracing. Position the sensor over the wheel attached to the servo to be tested. The wheel surfaces are a very flat matte black, so attaching a piece of light colored Post'it note may be enough to provide a leading edge to trigger the sensor.

The test program should look something like this:

' ----------------------------------------------

Reset the test data array and counters
'
' Cycle through the range of PULSOUT values to be tested
'
For range = low_value to high_value
    '
    ' move the wheel into test position
    '
    Zero the wheel
    Reset the time counter
    '
    Loop:
        Send a PULSOUT command to the servo
        ' in order to keep the timing constant, calculate the complement of
        ' the test value and send that to the other servo so that the elapsed
        ' time for both servos always totals to the same value
        Send a complementary PULSOUT command to the other servo
        '
        Increment the time counter
        Check the sensor
        '
        If the wheel has finished one rotation then update_data
        '
        ' as the values approach and pass through the zero movement point
        ' (around 750) the servo will move extremely slowly or not at all.
        ' In those cases this loop should time out.
        If time_counter = time_out then goto update_data
        '
        Goto Loop
    '
    update_data:
    '
    Store the time counter value in the test data array
Next

' ----------------------------------------------

The advantages of this approach are-

• Higher precision
• Automated process
• Repeatability - a major factor should it become necessary to change servos later

The primary disadvantage is -

• Test times may turn out to be very long

Note: The Parallax BOE-BOT guide is available on their website and can be downloaded free of charge. I haven't studied it in depth yet, but a quick read-through indicates that there are lots of helpful hints and good information for anyone starting out in robotics.

Robot Status Report - Maxwell

It feels pretty good to have Maxwell up, communicating, and actually moving around - even if he does hiccup from time to time. After my last post, I spent some time improving his motion, and cleaning up my code. After about an hour of tuning, he now makes repeatable moves, right angle (or really close to right angle) turns, and can spin in circles.

Experimentation with the program/servo timing highlighted the need to spend some time focused on two inter-related challenges-

• momentum/inertia
• motor timing/control

Momentum/inertia:

Maxwell's design is basically a symmetrical "wheelchair" model with the motion provided by two servos that have been modified for continuous rotation. He is relatively light - especially since I am haven't mounted a battery pack on his chassis yet and am still running him from a wall wart. But, as light as he is, the basic laws of physics still apply. It's really obvious from the testing and examining the videos that momentum/inertia is a factor that can not be realistically ignored.

To move Maxwell forward the program sends a series of balanced PULSOUT commands to the drive servos. Although the servos are mounted along the same axis, the orientation of their cases and drive shafts are exactly opposite each other. They have to turn in opposition (one clockwise and the other counterclockwise) at equal rates for Maxwell to move forward in a straight line. And, since their zero set values are slightly different, the values the program sends need to be offset to compensate for the difference. This is a simple calculation, easy to build into the program at a low level so that we don't have to take it into consideration later.

When Maxwell is 'at rest' - i.e. stationary, assuming that there are no external forces working on him, he is 'stable.' When the program generates a forward move from his stable state, he appears to start moving in a clean fashion and travels forward in a straight line.

The initial program ignored inertia. That approach worked fine for the initial move, but ran into problems as soon as Maxwell needed to stop. His mass is high enough that the friction/braking inherent in the servos isn't enough to stop him quickly. Testing revealed a small but not insignificant amount of overshoot.

In actual operation Maxwell will be reacting to his surrounding environment and changing course accordingly, so in most cases it might be acceptable to ignore this type of small error. Still, it would be best if his 'dead-reckoning moves match his real world moves as much as possible.

Quite a few of the competitors in the All Japan Micromouse competition had problems with dead-reckoning. They started off fine, but after a lot of traveling, turns, and retracing, they got confused about their orientation and sometimes ran into the maze wall. In order to re-establish their orientation some of them used a special move sequence that involved backing into a maze wall several times. This worked only because their rear surfaces were flat, and because hitting the wall in reverse isn't considered to be a 'touch'. I was told that a Korean competitor came up with this creative strategy several years ago. While that approach is certainly workable, it doesn't strike me as being a good engineering solution to the problem. It works for the Micromouse competition, but it probably wouldn't be workable in other contests or for exploring the real world outside the maze. Besides, I can't imagine trying to explain to my wife why Maxwell needs to hit his butt on the wall....

First, improve his movements as much as possible, then implement a sensor based orientation strategy.

When Maxwell needs to turn the program sends the servos another set of matched PULSOUT commands, only this time they are instructed to turn the same way - i.e. both clockwise or both counterclockwise. Assuming that both servos are fairly closely matched, and that there are no wheel traction issues, Maxwell should be able to rotate smoothly around his own centerpoint.

What really happens, however, is a little thing called rotational inertia...

Maxwell continues to turn slightly after the program thinks he has already stopped. Of course, the program could be modified to take the overshoot into account - perhaps by the addition of a small fudge factor. Unfortunately fudge factors have a bad habit of melting into sticky goo after a while.

If it's at all possible, it would be much better to figure out an approach that eliminates the inertial overshoot. This will probably involve using proportional or ramped signals to the servos to handle accelleration and decelleration as a part of the movement sequences.

Going back to the issue of dead reckoning, one of the programs to test Maxwell required him to run around a square.

The sequence was forward, turn left, forward, turn left, forward, turn left, ... etc. until he completed the square. If he executed everything perfectly he would end up exactly where he started with the same orientation.

He ran the first leg fine but overshot the end slightly. The first turn was a little more than 90 degrees - not much, but enough  to be noticeable. Naturally, the same errors continued and accumulated as he completed each leg of the square.

I haven't tried it yet, but it's easy to imagine what would happen if I put him into a long loop running around the course-

Fantastic, if you're building a Spirograph... Not so fantastic if you're building a working robot...

Motor timing/control:

There are several reasons why a better motor timing/control approach seems to be necessary. First, given the discussion above, the program control design needs to be capable of managing the servo motor accelleration and decelleration.

Second, everything I've read on the internet and in books recommends that servos work better if they receive a fairly constant control signal stream. If they go for a while without seeing a control pulse then they stop actively controlling the motor position. It may be a good design approach to send the servos control signals, even when no movement is required. Early in Maxwell's testing he would perform well but infrequently, almost at random, he would hiccup. Instead of rapidly spinning his wheels in the direction I expected, he would turn them slowly, sometimes in the opposite direction. However, when I modified the driver program so that the servos were always being sent a control signal, his errant behavior disappeared.

Third, and possibly more important, servos weren't designed for continuous use as drive motors. It seems to be common for servos used as robot motors to be pushing up daisies after about 100 hours of use. If the motor control program can treat the servos in a 'kinder, gentler' fashion, then they will probably live longer - and give the robot's owner fewer ulcers.

Maxwell's first driver programs were very binary. They used a PULSOUT using 500, 750, and 1000 values to command the servo to turn CCW, stop, or turn CW. While it worked, and Maxwell scooted around the desktop, it was obviously pretty hard on the servos. The servos made a lot of crunching noise, and the power LED on Maxwell's brain board would dim. A normal servo in an R/C or model plane application might react like this-

 

The green square wave represents the request from the control program (not the actual control signals that are generated.) For example, the operator throws his R/C model car joystick hard over to the right. The unmodified servo control circuitry generates an error signal and drives the motor until it gets the error signal back to zero. The red line above represents the relative servo position as it responds to the request. Its motor is only drawing significant current when the error signal is non-zero. Overlaying the two curves and looking at the area between them (red/yellow bottom curve) we can get a rough feel for how they interact, and how much power is pumping through the servo.

When the servos are modified for use as continuous drive motors their internal feedback link is deliberately disabled, and we replace it with software program control. If we just drive the servo in a simple fashion - full forward, stop, full reverse, then we're probably giving it a huge amount of stress and decreasing it's useful life. On the other hand, if the program can be designed to implement accelleration and decelleration curves, the servos will probably last longer. At least that's my current thinking.

Real Robot Movement

I put together a simple FOR ... NEXT loop to test the servo zero values. The first time around the loop range was from 700 to 800 with increments of 5. Every time it went through the loop it would send each servo a set of 50 PULSOUT signals with the current value, and display the value on the DEBUG console. Although I could see when the servo stopped moving, I found it was much more precise if I let my fingertip brush the wheel. Even the slightest motion was easy to detect using that technique.

Testing showed that the right servo stopped moving when the value reached 740 and started to reverse at 750. The same values for the left servo were 735 and 745. From this data it was pretty evident that both the servo's offsets from 750 and the difference in zero values between the two were contributing to the position and orientation drift.

The FOR ... NEXT loop was modified to range from 720 to 780 with increments of 1, and the test was repeated. The refined values for the right servo were 738 and 742. The corresponding values for the left servo were 737 and 739. I decided to use the mid-point for each servo, and modified the original program to reflect those values. Since both of the servos exhibited a slightly negative zero offset from 750, the forward and backward values were adjusted accordingly.

I reran the previous day's test program with the new values, and it worked great. There was still some relative position shifting, but very little. The next step was to get the robot to do something more useful. The first test was a rectangle move. Maxwell would move forward, turn CCW, move forward, turn CW, move backward, turn CCW, move backward, turn CW. That should bring him back to where he started.

The program was setup with several constants containing all the parameters in one, easy to change/adjust, place in the program. Maxwell, and the program, worked great. Nevertheless, I still have a lot of work to do to refine his turns. On the straight away his movement is almost perfect. But when he has to make a turn it's more difficult to get him to stop right at 90 degrees.

And, for some strange reason, every once in a great while, all of a sudden he decides to turn the opposite way from what I expected. This may be caused by the servo offset software approach I used. In any case, he's up and running around, not in circles but in a small rectangle on my desk.

Download rectangle.wmv (152 kb.)

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.

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.)

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)

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. 

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...

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

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.

Arrival

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.

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...

A Robot-ing We Will Go

Notes:

• All dimensions are preliminary rough estimates
• This robot has not been built - yet
• Kit source - Hobby Engineering, Millbrae, California
• I hate the color - but that's what spray paint was invented for...