Team Six/Paper

From Maslab 2006

Overall Strategy

We originally talked about using an arm on our robot, but decided that we wanted a more passive ball-acquiring mechanism, so we used rollers instead. Our “ball-gobbler” turned out to be surprisingly accurate at picking up balls and scoring, once we had it built. We decided that a wall-following algorithm was the best way to wander. The robot knew when it was supposed to have picked up a ball, because it had a “charge” mode that it went into once it had centered on a ball, and the ball collection mechanism could hold two balls at once, so our strategy was to have the robot attempt to pick up two balls, then search for a goal, dock, score, and repeat. This was intended to maximize our points for distribution among goals.

Our robot was designed and built to not get stuck against walls and protrusions, to be able to take a bump or two without being damaged, to be as precise as we could make it in mechanical and software design, and to be able to suck in and deposit balls accurately. Our software design used some emergent and some finite-state machine techniques to control the robot's behavior.

Mechanical Design

Who Needs FUSES!? was designed to meet certain operational requirements we set for our machine. The robot is immune to catching a corner on the wall because of its cylindrical form. Wheels located on a diameter of the chassis give a zero turning radius, which is useful for easily changing direction in tight quarters. It was decided early on that our method of ball collection would be a "gobbler" mechanism which sits on the front of the robot and actively absorbs balls into a storage silo. When a goal is approached, the balls can be forcibly ejected several meters by running both the robot and the gobbler in reverse. This gobbler mechanism consumed a majority of the Who Needs Fuses' net mechanical design and build time.

After determining key features and design parameters of our robot, around 18 hours were spent in the design phase. This involved modeling every aspect of the robot in SolidWorks. CAD let us make sure that all of our parts would assemble properly, and also gave us a chance to review our design before committing precious time to actual construction. Another side benefit was the rapid generation of blueprints, which made it easier for several team members to be working on parts in tandem. To avoid losing programming time during the construction of the robot (a process which took us up to the last several hours before impound), a temporary wooden robot was constructed with rudimentary sensors and a simple drive system.

Our final design called for many machined parts, which were divided into several major assemblies. The motor assembly consisted of a low profile motor mount which slung the motor as close to the chassis as possible, high precision axles and motor couplers turned on a lathe, and brass hub caps for the wheels. The ball gobbler operates by spinning two foam wheels separated a ball-width apart at high speed. When a ball comes in contact with the wheels, it is instantly forced through the narrow gap and trapped inside a holding silo. Each foam wheel is driven by a stainless steel shaft, which is supported above and below by ball bearings. A chain of custom-manufactured gears link both shafts (and consequently wheels) together in a manner which causes them to spin in opposite directions (thus maximizing their ball and bread-roll consuming potency.) Perched atop one of the two upper ball bearing mounts is a 12V, 18000 RPM motor whose spindle is set into one of the two stainless steel shafts. This powerful motor was tamed to decency by applying a scant driving potential of 2V.

The chassis revolved around the main 3/8" thick Lexan disk, which provided mounting for most of the mechanical components. Perched above was a slightly thinner disk housing the computational and sensor might of the robot. A final capping disk proudly exalts our dark lord Krotus, who's image is sandblasted into the quarter inch thick bulletproof panel. Riding several millimeters above the ground and below the gobbler wheels, a yellow acrylic kick plate supports the ball silo and provides a mount for the gobbler's lower bearing assemblies.

Well over 150 man hours went into our mechanical solution, and we are proud to say that every team member had a hand in machining parts for Who Needs FUSES!?

Software Design

The software was single-threaded by design, and behaviors were controlled by a complex network of functions that acted in a mostly-emergent fashion on their inputs. Non-emergent behaviors (like turning away from a goal to center on it, or "nothing's been interesting for a while, I must be stuck," were accomplished through state variables and uninterruptible "FDI" functions (FDI stands for "Do It!"). If mapping and odometry had been implemented, they would likely have necessitated multithreading, but unfortunately, time ran out.

This design was mostly sufficient for our needs, although a few problems cropped up with not removing behaviors entirely. Briefly we had experimented with a behavior to wall-follow on the left, rather than the right, for instance. When we removed it because it was buggy (possibly due to its slightly flakier IR sensor), we failed to fully remove it, and accidentally left a reference to it in a frequently called function, resulting in nonsensical left turns when the robot was in a tight space. This prevented our robot from getting through some bottlenecks. To be honest, the primary failure of our software was that our wander was not more robust. We should have spent a good deal more time on perfecting it.

The image processing was done by storing two images in memory – the input camera image, and the rendered output image. The output image had more use than just eye-candy, however; it was an integral part of the rendering process.

Each frame was gone through pixel-by-pixel, from bottom to top in each column and repeated incrementing x by 1 until the image was finished. If it found a blue line in a particular column, though, it would jump to the next column. If it found a red, green, or yellow pixel, it would do a flood fill on the object and try to determine what it was – note that we did not flood fill on black! The field had many shadows and all barcodes contained at least some green, so we only flooded through black if it was touching green. If it determined the object to be a barcode, it would read diagonals on each "square" and mark the read as good or bad based on aspect ratio, number of greens, and other factors.

The ouput image comes in because any found object was then marked on the output image. Then by checking new pixels to see whether they are rendered in the output image, we could skip over objects we had already found. Just for fun's sake, if multiple objects were found, they were marked in different shades. Also, barcode text was output to the rendered image, and a crosshair was placed on whatever object we were heading for.

It was suggested that we read rows rather than columns, since this would enable Java to buffer more intelligently, but we actually saw this result in a speed hit in testing, since we could no longer stop reading when we found a blue line, and had to actually process every pixel. There may have been ways we could have recovered that time, but we decided that the algorithm was Fast Enough® processing columns first.

The color processing was done via a modified version of the 16x16x16 RGB lookup table pioneered by Order of Random Cauchy last year. I like to call ours "The Lazy Man's Lookup Table," since rather than go through an elaborate and painstaking process of assigning individual colors beforehand, we merely generated the table on startup from our HSV thresholds (this took under a second). This certainly had wowee-factor, but we discovered that it didn't save that much time; only 20ms or so per frame. Other teams would probably find their man-hours more profitably invested in their navigation systems (our downfall).

Overall Performance

Who Needs FUSES?! emerged onto the Maslab playing field displaying its characteristic wall-follow behavior and menacing ball-gobbler in default GOBBLE! mode. Wall-following directs the robot in a gentle arc to starboard until an IR sensor is triggered. This allowed the robot to move into the playing field, eventually bringing the first ball into view. True to form, Who Needs FUSES?! stopped, centered the ball in its field of vision, and lunged forward, capturing Ball #1. The Ball Gobbler is most reliable when a ball enters dead-center, but it has been successful with misalignments of +/- a ball radius (it has also demonstrated the ability to gobble bread rolls, but for the safety of the public, feeding the robots is discouraged). Who Needs Fuses?! has a maximum capacity of two balls, so the bot set out for a second catch. Incidentally, the robot acquired its next catch unwittingly - the passive nature of the gobblers allows it to consume balls which were not detected in vision. Unfortunately, only balls that had been detected and deemed collected by the software are used to determine when the robot is "full". This could have been corrected by placing a switch or break-beam sensor in the ball bay to detect when full. Despite lacking sensing, the mechanical device fails safely - a third ball cannot be collected, nor will a third ball jam the system - but the software does not know to look for a goal until it thinks it has two. This caused the robot to ignore an easily visible goal (while full) to search for a ball it could not hold.

The robot did find a third ball. It centered and lunged, but could not collect beyond capacity. The software declared itself "full", and goal-search commenced. At this point, the robot discovered a tight situation. Who Needs FUSES?! seems to be claustrophobic; in tight spaces, the robot tends to turn too far when escaping from one obstacle, bringing it into contact with the next. A loop behavior emerged as the robot spun about looking for an open path. Eventually it emerged, though not before making some 'adjustments' to the playing field. Time ran out before the robot could locate a goal to score in.

Conclusions/Suggestions for Future Teams

Our robot, Who Needs Fuses?, finished in the upper part of the middle of the pack in competition, and also won the Best-Dressed Robot award. It did indeed turn out to be very accurate at collecting balls, and during tests, it was very accurate at scoring goals, but we did not get to see it actually attempt to score a goal during the competition, because it got stuck going in circles due to a bug in the wall-following code. Who Needs Fuses scored two points, and became an audience favorite when it pushed a protruding section of wall out of the way during the competition. The mechanical parts worked very well, although we had to attach the camera in place with hot glue because it kept spinning on the camera mount. We were reasonably pleased with how the robot did, but felt that it could have done better, especially since Brian figured out the probable bug in the code ten minutes after our time in the contest finished.

Who Needs Fuses?! was defeated by unreliable wandering. We invested a great amount of time into creating accurate vision (finding red balls, green balls, reading bar codes, identifying goals, centering a goal at scoring distance, registering goals with their corresponding bar codes, etc.), as well as in creating an attractive, sturdy chassis/gobbler. While these were rewarding efforts, a little more time thoroughly testing a wandering algorithm would have been time well spent.

That said, here is some sage advice for future teams:

• Get GREAT at bouncing around the playing field. Although IR sensors have lots of Bling points, don't neglect the humble bump sensor. Its fewer sensor points, and a bump skirt can give better coverage with less tweaking.
• Torque is Wonderful! As one of the largest and heaviest robots, Who Needs FUSES?! conscripted high torque motors to ensure that the wheels kept turning. Likewise, the Ball Gobbler used the largest motor we could find (requiring a separate controller and battery pack). Ask yourself "For a given RPM, why not have more torque?"... you'll be glad you did.
• Machining takes time. Lathes and mills are great tools that make great parts, but be aware that Accuracy = Time^3.