by Dennis Draheim
Rover: My First Robot
Rover started out as a LynxMotion Carpet Rover kit (no longer available). This is how he looked in August 1999. That’s a LynxMotion IR Proximity Detector (no longer available) kit on the front. The bump sensor is made out of a coat hanger and a pair of leaf switches.
Shortly after that picture was taken, Rover underwent some extensive modifications. I rounded his back so that he could rotate without getting hung up on obstacles, replaced the original First Step Basic Stamp I-based controller with a Basic Stamp 2-SX on a Next Step board, added a second deck with a Serial LCD display and a prototyping board, and mounted the IRPD on a micro servo so I could swivel it for front-facing obstacle avoidance mode or side-facing wall-following mode.
Rover competed in the DPRG’s RoboRama 99b and took First Place in the T-Time contest. Rover also took Third Place in the Line Following contest and in the Can-Can contest.
Rover’s been on the shelf since about February 2000, about the time I started working on Ortho of Borg. For the curious, you can take a look at Rover’s code (below). It’s not particularly well-documented, but there might be some useful tidbits in there for someone.
LynxMotion 5-axis arm modified to transport CDs
This is a LynxMotion 5-axis Arm kit that I modified by replacing the end effector with one suitable for handling CDs. My goal is to use this at work, where I write software to control semiconductor manufacturing equipment. I figure a CD is close enough to a semiconductor wafer to enable me to test my software. I hope to use CD-ROM drives to simulate process chambers.
So far, I haven’t had time to code up the kinematics equations to get the beasty to do smooth moves, though. If anyone has some code I could snarf, please email me!
Here are a few pictures:
- side view (large)
- isometric view
- closeup of controller (a Scott Edwards Mini-SSC)
Ortho of Borg: a collaborative effort between Tom Gralewicz and myself
Ortho of Borg is the brain-child of my friend Tom Gralewicz. Back in October ’99, I was lamenting with him the inherent inaccuracies of dead-reckoning using encoders on the wheels of a robot. Suddenly he had a brainstorm: since most of the errors occur when the robot is rotating and the wheels slip, what if you could make a robot that didn’t turn, but always moved orthogonally in the X and Y directions? The robot would no longer have a problem of knowing its orientation, because the orientation couldn’t change. A tight belt drive could all but eliminate inaccuracies in encoder readings for linear motion.
So Tom, working in secret, produced a prototype with some novel features:
- A 14″ square chassis with tracks on all four sides, mounted on pivoting struts
- Fixed axles between opposing sides to keep the pulleys on both sides moving in lock-step
- A powerful drive motor and gear train that drives all four tracks at once
- A gear motor driving a cam that pivots the track struts, raising one set of tracks and lowering the other, for direction changes
He unveiled the prototype to me in January 2000. It consisted of the bottom half of the robot pictured above (lower deck only), controlled via a wired pendant. He actually made it a belated Christmas present to me! I immediately decided that this had to be made into a complete, autonomous robot. I further decided that it should have its coming-out party at the Roborama 2000a contest on April 15th.
Given its size, this platform made it possible to use a PC for control. We initially looked at using a PC-104 board, but I wanted the robot to have sound, and sound boards for PC-104 were really expensive, so when Tom ran across some cheap 486 embedded computers (which we believe were pulled from cash registers), we decided to use one of these.
I’d been wanting to play with Linux to control a robot, so I loaded RedHat 6.1 onto the system. For the language, I chose Perl, because it’s powerful, can be run either interpreted or compiled, comes with Linux, and I’d been wanting to learn it for a while.
Using a PC (particularly one from the pre-USB era) presents some challenges for talking to hardware, due to its limited I/O. In order to make Ortho a viable platform, I needed to be able to interface the following:
- Motor controllers: one for the drive motor, one for the direction change motor
- An encoder connected to the drive chain; Tom found a nice 500 counts-per-inch one at American Science in Milwaukee.
- Sonar sensors to detect obstacles in each of the four directions
Software. The code for Ortho’s main controller is written in Perl:
The encoder and sonar code is in Microchip assembly for the Scenix SX-18 and SX-28 chip.
PatrolBot is a robot built into the shell of one of those rotating safety lights designed to be put on top of a car. It’s roughly 6″ in diameter, runs on 12v (8 Renewal rechargeable alkalines), and features 5 infrared range sensors spaced around the perimeter for obstacle avoidance (though the current program only uses the front three).
- PVC foam sheets used to make the chassis
- plastruct tubing used for the deck supports
- foam tires
I’ve found PVC sheet to be incredibly strong for its weight, and the plastruct tubing is easy to attach to it with #4 machine screws. Both take cyanoacrylate glue (superglue) very well. I used a 1/8″ sheet for the base, because I wanted to use the hazard light’s original retaining ring to hold the shell to the base; the top two decks were made with 1/4″ sheet. I cut them to shape with a scroll saw and smoothed the edges on a belt sander. The scroll saw did tend to melt the plastic a bit, especially the tubing. It helps to use a blade with very widely spaced teeth.
The foam tires are 3″ Dave Brown Lite Flite wheels, and are also available in a wider variety of sizes from Tower Hobbies. These wheels are very lightweight, and their foam construction gives them excellent traction. The only downside is they tend to pick up dirt when they are run across machine shop floors. 🙂
Rear Skid: Home Depot, cabinet hardware aisle (yes, it’s a cabinet knob).
Gear motors from Marlin P. Jones: These gear motors get about 160rpm at 12V under no load. No load current is about 110ma. Stall current is something over 700ma — I’m not sure because my power supply current limits at 700ma. I think with the load I was putting on them, I was getting more like 120-130 rpm and running about 200-300ma current (each motor). The motors work well on bare floor, but the robot does slow down quite a bit on carpet. I think the torque is somewhat less than what I get out of modified hobby servos, but the speed is about twice as fast on a bare floor. I’ll probably end up swiss-cheesing the decks with holes to lighten the robot up a bit.
BasicX-24 Microcontroller: This is my new favorite chip. In my opinion, it blows the Basic Stamp 2 and 2-SX out of the water. Not only is it faster, but its Basic language is much more powerful (it’s a subset of Visual Basic). It is pin-compatible with the Basic Stamp 2/2-SX, which means it has 16 general purpose I/Os; however, unlike with the Stamp, 8 of these can be used for analog I/O as well as digital. It has two PWM pins in addition to the standard 16 pins; these can be used to do motor speed control with no CPU overhead. It even has a pair of on-board LEDs (which show up as additional outputs).
NextStep controller board (board that holds the BasicX chip): This is a nice board, in that it brings out all the Basic Stamp/BasicX I/Os to 3-pin headers with the pin, power, and ground. It supports using a separate servo power
supply to run up to 4 servos. It has an on-board reset switch, two switches for input, and two LEDs for output.
Dual H-bridge kit (motor driver): This is an L298-based dual H-bridge board, similar in design to the one on the DPRG web site. I bought it because I don’t have the gumption to etch my own PC boards.
Sharp GP2D12 Infrared Range Sensor: These provide an analog reading, which interfaces very nicely with the ADCs on the BasicX chip. Acroname also has several other variations of these, which are interfaced in other ways. The main reason I picked these is because they were the cheapest ones in the family.
Using these allowed me to write a very simple and effective obstacle-avoidance algorithm. The ADCs give me a value between 0.0 (no obstacle in range) and 0.52 (obstacle very close). For motor speed, I needed to generate a PWM duty cycle between 0.0 (stop) and 1.0 (full speed). So I just took the value from the right front sensor, multiplied it by 1.8, and subtracted it from the left motor’s duty cycle. Similarly for the left front sensor and the right motor. Since the sensor’s output is nonlinear (kind of exponential as the obstacle gets closer), this results in veering away from an obstacle at a progressively sharper angle the closer it gets.
I use the front center sensor as a fail safe; if it sees an object too close, it disables forward movement completely and causes the robot to rotate in place until there is no obstacle directly in front.
The main problem with these sensors is that they give you only a single point of vision. It is easy for a narrow object like a chair or table leg to get between the sensors and cause the robot to get stuck. I plan to replace the front sensor with a sensor to alleviate this problem.
Safety Light shell: You’re out of luck guys, I bought that 20 years ago! I’m sure you can find something appropriate to use as a shell, though. As Ed Koffeman quipped, it does look kind of like a Jello mold. 🙂
Software. The code for PatrolBot is mostly written for the BasicX. The encoder routines are written in C for the cc5x compiler, and run on a PIC 16F873.