Team Fifteen/Paper
From Maslab 2006
Maslab Final Paper Team 15 – Virgin IR Sacrifice or Buffy Russell Ryan, Zack Anderson, Robert Gens, Conor Lenahan {rryan, zacka, rcg, cpl}@mit.edu
Contents |
Overall Strategy
From day one Team 15 governed itself by one fueling motive: to build the best robot we possibly could. With every engineering project comes compromise: there will always be a deadline to meet, and one must choose what he is going to attempt to accomplish. From the start we realized that we would have a high degree of success if we kept the design and functionality fast and simple. We wanted a robot that would not occupy itself necessarily with the powerball, precise alignment, and complex mechanical design, but rather, something that could quickly traverse the course and effectively pick up balls. We set out to spend much time on an efficient wander behavior, and a quick and effective method to acquire balls. In addition, we wanted an easy to fabricate and simple in design robot that would do it’s tasks with minimal chance of failure.
Mechanical design
Prior to fabricating the body of our robot, our team curled up in chairs around the East Campus desk and brainstormed designs. We had decided early on in the class that the robot would be circular with the two drive motors positioned so that we minimized the turning radius. A circular robot, we reasoned, would have less of a chance of becoming stuck in a complex concave playing field. We then discussed how that would affect such factors as the number of points of floor contact, balance, and center of mass. If we only had three points of contact, comprised of the motor wheels and a caster in the back, then there would be the risk of tipping forward. The lead-acid battery, it turned out, was an excellent counterweight to prevent this potential catastrophe.
After we established the basics of our design, our team then focused its discussion on ball acquisition. It was soon agreed that spinners or rollers would be a good mechanism to “suck-in” and “spit-out” the balls. As opposed to grippers or gates, rollers could quickly accelerate a ball into or out of a linear stack or queue. If we thought of the ball collection as a first in, last out (FILO) stack, then it would be easy to think about the power ball when programming. That is, we could take decisive action without worrying about disposing of other collected balls. Collecting balls with the spinner would simply involve driving over the desired balls. The spinner could be left in this state to prevent balls from accidentally leaving and could then be reversed when it came time to deposit balls in a goal. We had a couple options for this ball expulsion, though. A couple of us argued that an inclined collection track would be enough to force the balls out through the rollers. Others suggested using a servo or linear actuator to feed the rollers a controlled number of balls. The radial motion of the servo inspired designs of a circular inclined track with the motor arm sweeping down along the semi-corkscrew behind the balls. We spent a good deal of time deliberating over this design. It was rather neat, but it required a good deal of special engineering to figure out how the track would clear the height of our motors and how the spinner could somehow propel the ball radially while consuming the ball such that it would be sent tangentially up the track.
Sensors
The usage and layout of sensors changed over the construction of the robot, despite our best efforts to plan them. At first, we were rather set on incorporating optical mice (at least a pair to handle rotation better), but it quickly became clear that it would not be feasible for our team to implement them into the software. When it came down to the last week, we were devoting our energies to everything but mapping and odometry. That said, we did still have great success with our other sensors.
We relied heavily on the infrared range-finding sensors for navigation. Our original design called for two sensors angled from the robot’s path about 45° left and right. This allowed the robot to drive down hallways reasonably well, but the robot would not be able to stop itself from bumping into walls. We added a third center sensor for that purpose. The only problem with our arrangement of sensors was that each sensor was placed towards the edge of the robot. The way the IR sensors operate, however, causes faulty measurements when an object is held a close distance away. Testing the robot on the playing field, we saw the effects of this immediately; the robot would behave erratically if it drove within three inches of a wall. Instead of remounting the sensors, we added four bump sensors spaced regularly along the front of the robot. We weren’t able to design a robust collision sensor mechanism so the lever switches were practically exposed during the final contest. This turned out to be our weakest design point; the robot snagged on a concave wall segment and the sensor did not trip.
In addition to the sensors required for navigation, we employed the gyro sensor and an additional bump sensor inside the ball track. This touch sensor would tell our robot when it was appropriate to find a goal. The gyro was used reliably to measure accurate quarter and full turns.
Software Design
Our code was designed to meet one objective: pure EMATG (Elegance, Modularity, And Total Groovyness). To make a multi-person programming project to work well, the first two (the E&M) were critical. The “groovyness” came in from the code’s objectives. While many aspects of our code were similar to other teams, (i.e. we implemented threading to allow for several processes to occur simultaneously, scored goals by detecting the edges of the goal and centering upon them, etc.), we did have a number of more unique design implementations. For one, we employed an advanced wander mode that fused volumetric centering for corridor situations, and a wall-following/area scanning hybrid for open areas. To optimize for speed in the vision algorithm, scanning for all features was combined so the image processing would run in parallel as it iterated over the image only one time. This allowed us to skip techniques used for speed such as sampling every two pixels or picking random pixels. The general process of identifying a feature was to identify contiguous horizontal segments of color that matched the feature we were searching for, and adding it to a stack. After iterating over the entire image, segments with similar average-x values we're associated using a root-mean-square based procedure to cull outliers, and then grouped segments beyond a small threshold were then combined into a Feature object of the appropriate class type and added to a feature list that the image processing functions returned to the logic engine.
Overall performance
By the final contest, our robot had a mediocre overall performance. As we worked through the nights prior to the contest, we ran into a couple major hardware issues on both the OrcBoard and Eden minicomputer. Specifically, we believe that these issues were caused by our spinner motor. We are not sure why, though; the motor drew less than an amp of current at full power. Suffice it to say that replacing the OrcBoard and Eden did not fix the issue. Our band-aid solution was to delay the starting of the spinner motor until the robot correctly began its processing threads.
There were also a few issues with the software. We noted that our color calibration code didn’t correctly tune the camera to the color of the goal in 26-100. As well, we could have made a ‘smarter’ robot that would have navigated based on a basic memory of where it had been before. Without any of this higher order planning, our robot largely scurried around using emergent behaviors. While leaving this out was part of our original strategy of brute speed, it is hard to determine whether it was the right move since no other teams successfully used mapping for navigation purposes. It is not clear whether this was detrimental to our performance; the aforementioned issues tended to interfere with performance long before we could gauge the endgame navigation, collection, and scoring.
Conclusions/Suggestions for Future Teams
We walk away from Maslab with newly acquired wisdom. Some of it we feel should be shared with future generations, notably: thoroughly test questionable motors to ensure they work with the OrcBoard. We found that for the first week or so, we were programming merely to meet the checkpoints as opposed to developing overall code strategy and structure. While it is important to be able to meet these challenges early on, they should not be done at the expense of organization. First try to develop structure, and then start meeting challenges. Even if a team is a couple days late meeting a checkpoint, we feel that getting competition-grade code developed early on is a big time saver. Another suggestion for teams is to build a very reliable bump sensor configuration, or if at all feasible, a scanning rangefinder. Hitting the edge of a wall ultimately destroyed us in the competition because our bump sensor backup system failed. The last thing a team wants is for something trivial like getting stuck on a wall to end their game. Go to great lengths to create a solid detection system to check if the robot is stuck or not.
Generally speaking, team 15 is walking away feeling good about Buffy. We had a sturdy and effective mechanical design, extremely reliable ball capturing code, and an advanced wandering algorithm. Our two pitfalls were our frantic attempts in the last two days to get the OrcBoard to work, which ended up hurting us in many ways, and the second was that our goal scoring code could have been tweaked a little bit better. Occasionally the robot would misalign with the goal, or prematurely expel its balls.
While before Maslab the idea of controlling a robot using vision seemed like an almost insurmountable task, simple steps allowed us to effectively accomplish it, and in turn we learned a great deal.
