PolyBOTS

Trinity Firefighting Robot 2006

The First Year, by: John Mahlman IV

In 2006 the PolyBOTS wanted to take a chance at a robot competition, something we had never done before.  The then VP of PolyBOTS suggested a firefighting competition which he found online; it was small scale, fairly close to New York, and seemed like it could be a lot of fun.  We felt that this would be a breeze since it was such a small-scale competition and only needed a very small robot with basic programming.  We gathered a team of 4 people; Chris DiMauro, our resident tinkerer and Widget; Dave Hernandez, C code Monkey; Joe Cietante, other code guy;-) ; and myself, jack of all trades, master of few.  The team was set, but were we ready to do it?

The task is simple, go through a maze, find a candle in one of 4 rooms, extingish the candle, and do it all autonomously…and that’s it.  Other things are not touching walls, using certain methods of extinguishing, etc.  Best score wins! (for more detail please visit the Trinity Firefighting Home Robot Cometition website at: http://www.trincoll.edu/events/robot/ ).

The Design Nightmares

We took on the task fairly early in the year, around January 2006, the competition was in April.  We have plenty of time, but things kept happening and changing.  We ended up deciding on a kit (VEX), language (EasyC), and a course of action to put out the candle.  Design was another story.  Design lasted until the night before the trip!  Our original design used one fan designed for a PC case, one homemade IR sensor, a rigged limit switch for the fan, and 2 ultrasonic sensors for cornering and moving about the maze as well as a four wheel design; two drive wheels and two omniwheels.  This design proved to be fairly effective at cornering but due to the VEX controllers speed the sensors were slow at reading the path.  We later found that the EasyC coding was very annoying because it did not allow functions, and also cause the controller to respond much slower than it should have.  Obtaining a copy of EasyC pro would solve those issues, but that was $300 which we didn’t have time to get.  So trial copies of EasyC pro were used throughout.

Our final design was very similar to the original however we replaced the one fan with twin electric airplane motors and also replaced the rigged switch with a SPIKE from a FIRST robotics kit.  The SPIKE was much easier to use and looked a heck of a lot better.  The new fans were so powerful that it had the tendency to blow our homemade maze to the ground when testing.  Thus we dubbed the robot Happy Overkill.

On the night before the trip our real coding set in.  At 12 noon we were in the PolyBOTS room re-desiging, coding, wiring, testing, and drinking red bull.  It was a night to remember, and a night we should never do again!  Finally, at 5:43am the next day we were finished with design and code!  The only casualty was Joe’s PCI bridge controller in his laptop (apparently something with the VEX usb cable shorted out his controller and rendered his laptop useless for sending code, so my laptop was used instead).

We arrived at Penn Station at 10:30am to catch our train, fell asleep on the floor of the station because the train was an hour late but finally arrived in Connecticut a few hours later.  Checked into the hotel and slept for 12 hours.

The Competition

April 8th, the first day of the competition.  This was the qualifyng day, one successful run to qualify for the competition and we’re in!  We spend a few hours optimizing code, changing some basic design, and even attempted to build a second robot for the competition (we had 2 registered but only one complete).  Chris’s robot made use of a water pump and an empty Coke can, but we didn’t have enough sensors to fit onto the robot, so the second robot was completely scrapped.  Our first time up, we qualify!  We’re thrilled, but we still dont’ start celebrating because we still have the second day of competition.

April 9th rolls up, and we’re all ready to show everyone what we got.  You have three tries at th maze, all scores are averaged together, and the best score wins of course.  Our first run was using unedited code from the previous day, and no modifications to the robot at all.  The run is successful, and we’re in the top 10!  The candle was in the first room this time, so it was perfect for us.  After noticing other teams catching up we attempt to edit the code to make the bot faster, plus we used a completely charged battery for the second run.

The second run fails.  The robot is too fast for the sensors to read, and gets hung on a wall.  Turns out the full battery made the motors very fast, and the code also made the motors faster.  We lowered the motor speed and added a limit switch to the front to compensate if it gets stuck on a wall again.  Our tests in the practice maze were very good, so we go for our last trial!

The final trial starts well, the robot moves around the maze, passes the first room, then the second room.  As it makes it’s way to the third room it enters and runs around the wall as it’s supposed to (the candle this time was in the last room!) but on the last corner it got stuck to the wall.  It did manage to hit the limit switch and attempt to compensate for the wall, but the compensation was too little and it ended up wedging the robot against the corner where it couldn’t hit the switch again.  Our third run fails.

Defeat and Learning

Because we had only one successful run, our robot did not place in the competition.  We did do better than many teams at the competition (many didn’t have any successful runs), but the Chinese teams defeated everyone at the competition with their pre-built robots.  Although we did not win anything, we walked away with a great experience and knowledge for future attempts at the competition.  Happy Overkill will forever be in the PolyBOTS hall of fame.