The kit we were given at the start of the course contained an abundance of parts to choose from, both mechanical and electrical, from which we had to construct our robot. Here we describe each of them and the experiences we had with them.

LEGO Pieces

Lego pieces provided the mechanical backbone of all robots. We received a lot of LEGO pieces in all sizes and shapes, most of which we eventually used in our robot. They were strong and do not break easily. The relative ease of putting them together and tearing them apart allowed us to go through a few different design iterations without too much trouble. We did wish there were more of certain parts, however, namely friction pegs and yellow bushings.

Distance Sensor

The distance sensor was our primary tool for positional error correction.  We mounted two of these sensors, each one on a servo.  When we believed ourselves to be in an uncertain position, or when positional accuracy was important, we would use these to reposition ourselves with respect to the game board.  The distance sensors would look in each of the four cardinal directions to look at the walls, and then out of the possible points, we pick the one that is closest to our expected position.  The fact that we have two reduces the risk of being thrown off by a robot or the flagbox.

Bump Sensor

We had two bump sensors on our robot.  The first doesn’t actually affect the robot’s behavior.  This one is present in the jaws of our robot, and should be depressed when we have acquired a ball.  However, we didn’t implement behavior for whether or not a ball is actually acquired.  The one we use more is on our lift.  Our four-bar mechanism is driven by an unlocked servo.  This implies that the positional encoding of the servo no longer works.  Therefore, we treated the servo like a motor, since it behaves as such when given overly small or large values.  The servo is then told to stop once the switch is hit.  The switch was placed in such a way that it is depressed when the lift is both at the top and the bottom of its trajectory.

IR LED/Phototransistor

We have three IR LED/Phototransistor pairs mounted on the bottom of our robot, arranged perpendicular to our robot’s direction of travel.  They were arranged as such to support line following, although this feature was never actually implemented since our driving methods seemed nearly as accurate and much faster.  Instead, we use them to find lines.  We only use this feature at one point – searching for the flagbox.  When the robot is ready to attempt the flag raise, it searches for the line in front before attempting to raise the flagbox.  These were calibrated before every match to permit resilience to different lighting, thermal, and board conditions.  Each LED was given several light samples and several dark samples, and chose the threshold between light and dark to be the midpoint.

Shaft Encoder

The shaft encoders were mounted on each of our wheels, positioned to be in a 15:1 gear ratio with the tires.  These were used as our primary method of distance estimates.  When traveling at a known angle, we get a fair estimate of our final distance from the information retrieved from theses sensors.  This does not account for skidding or perturbations encountered during the path, but it was accurate enough, since we periodically update our position from the distance sensors.

Gyroscope

The gyroscope was our main tool for driving in a straight path.  We were provided with tools to convert the angular velocity information to an angle at any point in time.  This was found to be extremely accurate when calibrated properly, which is why we based most of our navigation system on it.  The gyroscope’s calibration routine was run before every match to provide immunity from such fluctuations as those brought on by battery life.

Motor

A standard low torque motor. In order to gear them down, we had to LEGOize them. Our motors never gave us any problems even though we run them at close to max speed.

Servo

We used servos for the lift, jaws, and our distance sensors. The OS is unable to control an unlocked servo past its normal range of operation so we had to figure out other methods of feedback to stop our lift servo.

Happyboard

The Happyboard was a very useful and reliable piece of equipment.  We had no irreparable hardware failures.  There were plenty of pins for interfacing with external components.  4KB of memory was quite sufficient for an application such as this.  There was one hardware issue of concern at one point.  The board would crash shortly after booting nearly 25% of the time.  While we were initially unsure of the cause, we eventually found a short circuit on one of our sensors, and its repair stopped the board’s crashing.  It did not seem like the board suffered any permanent damage from this error.  The pin connections on the board were pretty standard, so mounting the wires to the board was never a problem (although connecting the wires to the sensors was sometimes challenging).  One modification to the board was necessary, although simple.  Some traces on the back of the board had to be severed in order to support use of the distance sensors, since they do not require the use of the built in pull-up resistor.  This was easily accomplished with a razor blade.

JoyOS

JoyOS 0.2.4 RC4 was the operating system on which our robot ran.  It was generally a good operating system; it could do most functions perfectly.  It was not without some bugs, however.  Many were patched in the mid-IAP OS upgrade.  This upgrade provided several challenges for us.  The gyroscope code was rewritten, and, even when our values were converted to function with the new convention, it still resulted in faulty readings.  We had to recalibrate from scratch, which, for a good level of precision, takes quite some time.  It was disheartening to have a robot which couldn’t even drive straight after having been on schedule just days before.  However, this problem disappeared when the gyro was recalibrated.  One other problem the OS has is the difficulty associated with debugging.  The primary way of debugging is usually the LCD screen.  After many problems, we realized that calls to the print function appeared to be blocking.  There are several ways this became apparent to us.  When trying to get turning to work, it would always overshoot, and its corrections seemed to take place on a discrete time interval.  As further evidence, when we tried to write our code to drive until a line is reached, the robot stopped about a foot after it crossed the line.  These were each traced to the print statements, which could introduce a delay of up to a second.  After this, we only used print statements when absolutely necessary, and none appeared in our final robot outside of the calibration routine.