The robot is trying to kill me!
The goal of this project was to build a robot capable of navigating through a maze and extinguishing a candle. The maze configuration, along with the placement of the robot and candle, are not constant. Despite this, there were certain restriction on the possible layouts of the maze.
Our initial concept was of a compact, wheeled robot that would use a fan to extinguish the candle. The robot would have bump sensors, allowing it do detect collisions with the walls of the maze. Infrared detectors would be used to detect the flame of the candle; upon locating the candle the robot would activate the fan, and return home victorious.
There are a few basic requirements for our mobile platform. It has to be (a) mobile, and (b) a platform. That is, it has to be capable of moving through the maze effectively, and reasonably quickly, without getting stuck or tipping over or catching on fire. Also, it has to carry the Handyboard, sensors, and other equipment safely, in such a configuration as to allow for detection and elimination of the flame.
The locomotion system is a two-wheeled differential drive. The wheels are mounted along the center axis, allowing the robot to turn holonomically. We used high-speed, low-torque Lego motors, and so a considerable gear reduction is used to get reasonable drive output. The first stage of the gear train is a pulley system, to reduce noise and eliminate some gear binding problems we encountered. The drive system also uses two Lego quadrature shaft encoders for rotational feedback.
Our candle sensing and extinguishing platform is mounted above the main chassis, at the candle level specified by the problem statement. Three QRD114 Infrared reflectance sensors are used to detect the candle. With the emitter portion of the sensors disabled, these units give a usable range within which we can detect the candle, without the possibility of false detections from the intended use of the sensors (that is, obstacles in the maze). There is a centrally mounted sensor, along with one on each side (all forward-looking), so that the robot can determine the direction of the candle relative to its current heading. A 12-volt computer case fan, hooked up to one of the Handyboard's motor inputs, is used to put out the candle.
A bump sensor array is mounted on the front of the robot. Two contact switches allow for detection of obstacles on the left or right sides of the robot. Since the maze specifications prevent any particularly tight passages, and since we don't anticipate significant amounts of reverse or transverse motion (turning should all be within the robot's own radius), there is no sensing capability on the rear or sides.
The code for our robot is written in Interactive C. Control is divided into two operational modes - searching for the candle, and extinguishing it.
The search system is built around a subsumption architecure, with three high level behaviors - obstacle avoidance, candle seeking, and wandering. These three behaviors are spawned off as separate processes, and a manager process mediates between them, selecting the action specified by the highest-priority behavior. Thus, if no other stimuli is provided, the robot will wander, which in this case means traveling forwards. If an IR sensor detects any illumination, the candle-seeking behavior subsumes control and turns toward the light source, dropping to extinguishing mode if appropriate. However, if either bump sensor is activated, the collision-avoidance behavior subsumes control, backing the robot up and turning it.
The act of extinguishing the candle is somewhat more straightforward than searching for it in the maze. The robot simply has to activate the fan and monitor its IR sensors until it appears that the candle is out. Upon further testing, the IR readings drop to an indistinguishable level when the flame is burning very low, so in practice, the robot waits for a reasonable interval after it thinks the flame is extinguished to make sure that it hasn't flared back up. Also, the fan is most effective when the candle is slightly off-center, and so the robot might rotate back and forth a few degrees to maximize the likelihood that the flame gets put out.
While the IR sensors are responsive to the candle, and don't tend to have false triggering, the readings tend to fluctuate quite a bit. In order to stabilize the values, we spawn off a separate process that continually samples the sensors and averages their results.
Our initial chassis was built around a four-wheeled, rear-wheel differential drive system. This drive system was effective for forward and back motion, but turning proved difficult. If one wheel was turning in reverse and one turing forward (which was the most expedient method of turning), the reverse wheel would tend to slip, which made our encoder counts invalid. Also, the undriven front wheels would tend not to turn and therefore generate quite a bit of friction. We got around this issue by changing our design to two center-mounted wheels. By being mounted along the center axis, the wheels share equal loads when turning in opposite directions. For balance, smooth skids are placed on the front and rear.
It sorta works. Then it tries to ram the candle. Andrew is afraid that the robot is after him. He may be right.
But seriously, all of our robot subsystems operated fairly well. Once the robot got in front of the candle, it could successfully extinguish it. Collision avoidance worked and was responsive. And, the robot can wander around just fine.
One of the problems we had were with complicated locomotion - depending on the charge state of our batteries, the robot can get hung up in the carpet of the lab. Performance is much more reliable on the tile floor. Aside from that our main problem was with integrating all of the subsystems; because of the multiple processes and the limited debugging possibilities, it was hard to trace exactly what the robot was trying to do.
Our project was successful in that the robot does each of the behaviors it is supposed to do. However, it does not always do them in concert. We would have benefitted most from having more time with a working hardware design to debug and integrate the control software. Also, for much of the development time we were working without salty snacks, which seriously inhibited our productivity.
Over the course of this project, we did come to realize that constructing an acceptable chassis was not as easy as we had thought. We went through a couple design iterations before we came up with something that would give us semi-accurate motion, especially turning. While Legos are extremely versatile, and great for rapid reconstruction and prototyping, they aren't the most solid things in the world, and the motor and drivetrain capabilities leave something to be desired.
As the following sequence of pictures will indicate, we have strong reason to believe that our robot has acheived artificial intelligence, or at least enough intelligence to harbor (well-deserved) hatred.