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.




Read More

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

Read More

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.

Read More

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.

Read More

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.

Read More

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.

Read More

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.

Read More

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
        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
    Store the time counter value in the test data array


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.

Read More

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



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.

Read More

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

Read More