Robot:
We started working on our competition robot on day one, planning out the best way to work the table and trying to find a strategy that would essentially guarantee victory (assuming we would have plenty of time to make sure it executed correctly). What we eventually decided was that it was in a robot's favor to have as many balls as possible. It would be even better to know what color the balls were so that at any given point in the round, the robot could go pick up balls at known locations or clear out known ball areas (like the other team's scoring zones). The beauty was that one didn't need to rely on balls being anywhere, because the robot would know what to do with any ball it encountered. We ran through a number of what-ifs and alternate approaches, but we eventually decided that our robot would be rather weak without a ball sorting system.
We spent a good amount of time brainstorming (including visiting past years' websites) to find a good way to get balls into a sorter. We eventually came upon the somewhat sketchy but also somewhat promising idea of placing a set of rotating wheels in front of the robot in order to whip the balls up into our robot. We also created a ball-sorting mechanism that consisted of two angled Lego pieces forming a holding tray with a light and a light reflection sensor mounted appropriately. A servo underneath would tilt the tray to either side depending on the ball color. Despite the ridiculous complexity, we had this implemented Madd Fast (TM). By the end of the week we and the 6.270 organizers were amazed and excited about how cool it was. The ball pickup wheels were more powerful than we'd imagined and were even throwing balls all the way over our robot (a problem we figured would be easily fixed later on). We soon had a good basic robot design where the cavity within the robot would easily hold 11 balls of each color under the robot, on the floor. We wanted 22, but hey...
Quite the auspicious start for early week two.
We decided that our robot needed to be the best out there, especially since we were so far ahead in the game, and that meant...Electronics Modifications! The first of which was to upgrade the motors in the robot from the wimpy ones included in our kits up to some bad boys with actual torque. We found a few cheap ones on allelectronics.com. These bad boys worked at 6-12 volts but drew over an amp at no load and around 3 amps at stall. We needed to make sure that sure they didn't blow up the HandyBoard. We built motor driver expansion boards on which we mounted two stacked pairs of motor driver chips in the hope that four motor driver chips could dissipate the thermal energy from all that current draw.
Around the same time, we upgraded to the Hawker batteries, which we assumed would only boost the performance. Instead they left it weaker since the HandyBoard’s old NiCad's had been providing power at 9.6 volts versus the organizer recommended 6 volt Hawkers. We eventually decided that we'd just power the HandyBoard off of 6 Hawkers providing 12 volts directly. We purchased some non-volatile memory so that when we disconnected the Hawkers for charging we didn't lose all of our code.
In the process of getting all this done, we ran into a large number of electrical problems that may or may not have been resolved completely by contest day , but which included blowing the main Handyboard inductor rendering it inoperable until it was bypassed, blowing two NAND gate arrays, and a whole bagful of motor drivers, plus burning off the insulation on the servo trace on the expansion board.
Meanwhile, the robot's drive train was still an issue. We went through a large number of iterations as we tried to optimize the gear ratio and overall robot robustness (taking into account mounting the motors and remembering that our new motors were coming soon). We tried to reduce the electrical strain on the Handyboard when our robot hit a wall and pulled the motors at full-load (a.k.a. lots and lots of current). We didn't want to destroy the design of the ball intake modules that already worked fairly well, but had to more times than one out of necessity. In the end our robot wasn't able to consistently navigate the playing field because we simply didn't get enough time running on the table.
Our ball release system also went through a few revisions; we wanted a way to leave behind balls that were stored in our bot (they would have already been on the floor), so we needed gates or doors that were one way, but only allowed that motion when we actuated them. We started with the Lego equivalent of garage doors powered by a single motor on a dual differential gear train with rubber bands for restoring force, but those seemed a bit flimsy, so we went to a rack and pinion system that would slide the gates up the back.
versus
As far as programming went, we very much were relying on the gyroscope and the RF system working for us. Early on, we already had functions like go_to_point(x,y) that would take the robot to any point on the board from any point on the board (with timeouts, of course). The benefit, of course, was that we could script a path to follow, and even if the bot didn't do that perfectly, we still were moving through a route on time and picking up (sorted) balls. Near the end of the round, we'd just drop off the balls and score a ton of points. What we unfortunately found was that neither the RF nor the gyroscope were perfect (or even accurate in the analog sense). We spent a lot of time trying to figure out why not, even going so far as to add to the RF code to check for updates so we weren't using old coordinates and writing four or five different versions of the go_angle function in the code distributed by Analog Devices. We eventually gave up on RF as a form of navigation and of the gyroscope as an accurate device (we decided it is so long as you give it processor time), but we had no time to change our driving system to one based on shaft encoding.
LINKS: