|
|
Harvey Mudd College
|
In place of a second lab project, our group purchased and constructed a small robot kit. We selected the Rugged Terrain platform from Lynxmotion, a four-wheeled design with a segmented chassis which allows the robot to better handle uneven terrain. We encountered many challenges constructing this kit, some that we expected and some that we did not. The ultimate goal is to implement a navigation and path finding algorithm, which will likely require that additional computing power be provided by a remote system. We hope to enable our robot to communicate with that remote system by means of a wireless data link.
Before selecting the Lynxmotion kit, we considered a variety of robot platforms and controllers. We learned that in the hobbyist range, controllers generally consist of Motorola 68K-based systems, which are programmed using a variant of Interactive C (such as in the Rug Warrior, or the Handyboards), or the slightly less expensive "Basic Stamp" processor, which interprets a language called PBASIC. For a chassis, there are several choices of wheeled platforms in the $100-300 range. Most bases offer two to four powered wheels, and some include encoders to measure distance traveled.
 |
| The Basic Stamp processor mounted on a Next
Step controller board. |
The package we selected from Lynxmotion included a four-wheeled chassis, a Basic Stamp processor with a Next Step controller board, and an infrared proximity sensor kit. We chose to upgrade the processor to the BS2e, which has four times the memory of the BS2. The package cost approximately $300.
Looking for a wireless serial adapter, we encountered more difficulty. We found that commercially available products tend to be oriented towards wireless networking of PCs, meaning that many are unsuitable for a robotics application (too large, require AC power, etc). Also, such products generally cost over $500. Industrial radios can be purchased for embedded applications such as ours, but large suppliers are unwilling to sell in very small quantities (e.g. 2), and such equipment also tends to be expensive.
We were able to locate one product that looks promising, the Inno Media Infowave IW-9000 wireless serial adapter pair. Unfortunately, the product seems to be discontinued (or at least very poorly distributed), and we were unable to find a vendor with any in stock. We contacted Inno Media directly, but they did not return our phone calls or e-mail. We finally located one pair on eBay, but unfortunately they were purchased by a researcher in a robotics lab at the Neurosciences Institute in La Jolla. That researcher has offered to sell them to us if they don't fit his application--although we may not want them in that case, since his application is identical to ours. As of this writing, we are still uncertain whether we will be able to acquire a wireless serial radio pair.
For the host system, we borrowed an HP OmniBook computer from Harvey Mudd. The OmniBook presents its own challenges, since it seems to work only in its docking station, and not very reliably even then. We were eventually able to install Windows 98 on one of its two hard disks; we chose to install Windows because it is the operating system that two of our three group members are most comfortable with. We will eventually need to develop an application to run on the OmniBook which interfaces with our robot through the serial port and will be capable of reprogramming the robot on the fly.
The robot kit arrived mostly as we expected, in component form. The Next Step controller and IR sensor board needed to be assembled, which Dave did while Woody and Mike undertook the assembly of the chassis. To our dismay, we discovered that the included motors are only capable of rotating a half turn. Before they could be used for locomotion, they had to be taken apart and modified. We found the procedure for modifying the motors difficult at best.
 |
| One of the HiTec servos disassembled. |
Even after successfully dissassembling a servo into a collection of gears and tiny bits of hardware (which was no trivial task), the modifications required were not simple. We had to follow an elaborate procedure to rip apart a potentiometer and hammer down a mechanical stop inside (thus permitting the pot to rotate full circles). This process, at least in Mike's hands, had an unpleasant tendency to damage and deform the pot casing in exactly the way you might expect would happen if you were to pound it with a hammer. We would have liked to simply remove the pot altogether, since it is no longer used anyway, but unfortunately one of the necessary gears mounts on the pot shaft. In attempting to bend one of the pot casings back into shape after hammering it, one of the pot casings tore free of its bushing altogether. Fortunately, this doesn't seem to matter, since the bushing and its rotating shaft are all that's required, leaving us to wonder why we didn't simply tear apart the other three pots in the first place.
Meanwhile, Woody's task was to cut a tooth from one of the servo gears to permit it to rotate full circles as well. Following the kit instructions, he attempted to cut it loose using a razor blade, which proved as ineffective as it was dangerous. He then discovered that it could easily be removed with a pair of snub-nosed wire cutters. Once Dave completed the small resistor network that we had to solder in place of the potentiometer, we were ready to reassemble the motors.
| A highly modified potentiometer of our
own semi-intentional design. |
During this process, we observed that our modification procedure would destroy the feedback capabilities built into the servomechanism, effectively leaving the robot with no means of closed-loop motor control. We fear that this will be a significant disadvantage for our intended navigation applications. Overall, the motor modifications consumed the bulk of the overall assembly time and we seriously question whether more appropriate motors could have been included with the kit.
While Woody and Mike finished assembling the wheels and mounting the other hardware on the chassis, Dave finished soldering the electronics. Before mounting the controller on the robot, we were able to verify that it worked at least enough to communicate with the computer and print some debug messages. Without the servos and sensors attached, there was little more we could do to verify that the controller was operating correctly. After mounting the controller, we immediately discovered that the robot's left front wheel blocks access to the serial port.
Overall, we feel that if nothing else, the assembly of this kit amply demonstrated the compromises that must be made in robot design. As previously stated, we cannot help but believe that the motors included with our kit were less than optimal. From an educational perspective, some properties of the kit may have been advantageous, because it required the builder to be involved at a very low level with both the electronic and mechanical components. Should any of us be again required to hammer potentiometers into different shapes or hack teeth off gears, we will be well prepared.
|
| The battery holders and servomechanisms are visible on the underside of the robot. |
We have now completed the electronic and mechanical assembly of our robot as supplied, and it appears to work as the kit's designers intended. Our next task will be to add more sensors and hopefully mount a wireless adapter to the serial connection. We have a single sonar rangefinder, mounted on a servomechanism, that we hope to be able to use to give our robot long range sensing capabilities. We may decide to install bump sensors if the front IR detectors turn out to be unreliable. A rear bump sensor might also be useful, although we can probably work without one. We may also need to install our own wheel encoders, depending on how consistent the motor speeds turn out to be.
We will also need to become familiar with the Basic Stamp's PBASIC programming language. There are early indications that communications between the controller and a computer will be less than perfect (e.g. the controller gets confused easily and requires hard resets), but this is similar to the Rug Warrior's behavior and might be unavoidable. We plan to do most of our programming on Dave's computer, and copy what we need to the OmniBook for later demonstrations.
Report by M. Dickerson, 26 February 2001