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