03 May 2012

Our Tabletop Robots

Our team had three robots competing in the tabletop competition.
Luke's Robot

Ben's Robot

My robot


All three robots had two-wheel differential drive chassis from a variety of sources. Two of the bots used cheap motors and wheels from DFRobot attached to home-made bases made from aluminium sheet or from thin MDF.





The third robot used this platform.

The control board for the boy's robots is the DFRobot Romeo. This is an Arduino-based board designed with robotics in mind. It has 3-pin headers for every I/O port providing VCC, GND, and signal pins allowing sensors to be easily connected via 3-wire servo cables. There is an on-board motor driver for a pair of motors, a series of buttons, and a socket for an X-bee module. These bots have an LCD display with an I2C interface to save on pins.

I was using a custom-made motherboard with sockets for the microcontroller board, the LCD panel, the motor driver board, some buttons, and some pin headers for the spare I/O pins.  The motor driver I used was the Sparkfun Motor Driver 1A Dual TB6612FNG sourced via Mindkits. The microcontroller is the Teensy, again through Mindkits.  This is an AVR board with high compatibility with the Arduino but with several improvements.



We were all running stereo ultra-sonic ranging sonar for can location. These are similar to a Ping))) and require a single digital pin.  They return a pulse length for distance to the closest object detected.  More complex sonars have the ability to return multiple target distances but we went with what we had.  The challenge was balancing the desire to scan across the entire table against detecting objects near the table (like people).


We all developed similar "arms" in the front of the robot to corral the cans and allow them to be pushed off the table.  Our arms could hold a can where the sonar couldn't detect them so we added some proximity sensors to detect the presence of a can.  We had some I/R proximity sensors (some robbed from Ernie) so we employed these and they worked really well.  The in-built LED indication and the internal pot adjustment allowed calibration without programming.

You might notice my robot had some wires across the back of the arms.  This was a last-minute bodge as the edge-avoidance code wasn't properly tuned to allow the robot to tip the can off the edge of the table when it was being held so far back.

For table detection the boys were using some analog sensors from Pololu (via Mindkits), that we had bought earlier with the intention of doing some line-following. I foolishly thought we had more of them than we did and left my ordering too late to allow for international shipping.  Fortunately Mindkits had some Optical Detector-Phototransistor-QRD1114 (the through-hole equivalent part used on the Pololu board) in stock and I made some boards using a couple of resistors and they worked well.


I was also using the circuit board out of an old PS2 ball mouse for reporting wheel encoder counts and button clicks for my LCD menu navigation.  The encoder assemblies were removed from the mouse and hot-glued onto the robot but I did not get encoders working for the comp. I suspect I might have something not well aligned but ran out of time to troubleshoot.  The advantage of the PS2 mouse is that you don't need interrupt routines in the main micro as the PS2 mouse can be queried for cumulative and current encoder counts together with status of up to 3 buttons.

All of our source code was based on a behaviour subsumption engine that Ben and I wrote a while back which we branched for each robot. Ben coded all behaviours etc himself, Luke specified the psuedo-code with me writing most of the C code for him and Ben helping him to tune it. Luke's next task is to learn C programming properly and take over his own coding.

The next competition will be more of a challenge.  The table will be rectangular so we will need to reposition our edge detectors and avoid/ escape behaviours to allow us to get into the corners and out again in case there is a can there.  Details are yet to be finalised but we may have to get the cans into a goal instead of simply tipping them off the edge.  That would require can capture rather than simply knocking them off the edge.

No comments:

Post a Comment