Report 2 (2/18/04)Equipment Checks and Scoring StrategiesBack to main pageTimeline (Updated 2/18/04)Here is a rough outline of the current plans, and what's been accomplished thus far: Timeline for Project 2
Accomplishments to Date
Progress and Performance ResultsSensors and MotorsWe've tested out the various sensors available for the HandyBoard. These include digital touch/bump sensors, light sensors, IR rangefinder, IR tophat sensor, sonar and CMUcam. The touch/bump sensors return a 1 when pressed and a 0 otherwise, and all work fine. The light sensors return an integer between 0 (bright light) and 255 (darkness), and work correctly. The IR rangefinder is supposed to give distance readings to an object; however, we could not get the values to vary beyond one or two units, which clearly is unusable. After looking around on the Internet, we determined that we would need to modify the HandyBoard to use these sensors, as their voltage output is too low for the resistor on the HandyBoard. Since we're not supposed to modify the HandyBoard for the competition, these sensors seem to be unusable. In our experiments, the IR tophat sensors returned a value around 10 when pointed at a nearby white surface, and a value around 20 when pointed at a nearby black surface. So for close-range dark/light color sensing, these should work. The sonar sensors can supposedly detect a range between 3cm and 3m. We did get them to return a value to the HandyBoard which appears to be correct. The code to run them was found on the Internet, and some values are hard-coded in it, which require the sonar sensors to be plugged into specific ports on the HandyBoard. This is an acceptable limitation, though. We need to do some more careful tests to make sure the sensors are calibrated correctly and returning correct values. We also have the CMUcam working at least minimally. We cannot get it to connect directly to the computer; however, we have code running on the HandyBoard which uses the color detection functions in the camera to identify blue and orange blobs. One inconvenience in working with the camera is that it completely disables communication with the computer over the serial interface. This makes it necessary to reset the HandyBoard in order to reprogram it. The color-detecting functions we tested were more likely to detect orange even if none was present than to detect blue. Detection of orange seems to include brown, where detection of blue only gives high readings with light baby blue objects and barely detects Lego blue. Additional experimentation with the camera is needed to determine these types of ideosyncracies in its color matching and to explore its other features. We also hooked up a motor and servo motor to the HandyBoard to ensure these worked. The motor is hooked up to one of the four motor ports on the board, and using the built-in functions we can drive it forwards and backwards at variable speeds. The servo motor was connected to one of the servo ports on the expansion board. We were able to successfully set the servo to values in the range of 0 to 3000, which covered the range of the servo. Arena Construction StatusAll of the necessary parts for the arena have been acquired besides the 4' x 8' tile board and ping pong balls. All of the PVC piping has been cut except for 2 pieces (the mismarked pieces in the parts inventory which has since been corrected by botball.org). The PVC, toilet paper rolls, ping pong balls, and scoring baskets still need to be spray-painted. All of the the work necessary to complete the arena can be completed in a day's work. From observation of the arena layout, several things become immediately clear. The most important thing to recognize is that since the RCX box only has one IR sensor, it can only use the information provided by the black tape on the floor to navigate the arena. This means that an RCX bot can only interact with the toilet paper rolls and the nest; this means it can't score points, limiting its role. Additionally, playing the white side may prove difficult because everything will be the same color; for the handyboard bot, it is not unlikely that only sonar and the tape on the ground can be used for localization.
Scoring Strategies and Bot DesignAfter discussing various possible scoring strategies, electronic limitations and architectural considerations, it was decided that the team would adopt a two bot strategy: the smaller, simpler RCX bot would attempt to navigate the arena using the black electric tape on the ground, while the Handyboard bot would travel the arena vacuuming ping pong balls into its collection receptacle. The main design limitation that arose was the size constraint of the entire structure; the robots must fit into a 12l"15w"x12h" shoebox, and an equivalent 12"x15" starting area in the actual arena. This is a primary concern because the most common sense approach for scoring would consist of collecting any number of balls and tubes into a bin on the robot itself, and then making a single stop at a scoring bin (unlike last year, tubes and balls only score if they are actually put into scoring positions). However, it was obvious from the size of last year's bot as well as the size of the bots in the videos from the last year that having a bin on the actual bot would take up most of the available footprint space. This gave us two options: either we could go ahead and plan a two bot design, with the secondary bot fulfilling a role that could later be pushed onto the primary bot if size constraints didn't permit both bots. Or, we could plan a single bot from the start. The team decided on a two bot strategy for three reasons. Because the RCX box would play a minor defensive role independent of the Handyboard bot, it could be easily removed from the strategy if space proved too limited. Additionally, the design of two bots would more easily facilitate all five members of the team working on them concurrently. Finally, it would be easier to overshoot the design, and then reel it in later if it proved too ambitious rather than starting with too simple of a design that couldn't be upscaled. The RCX bot is limited in its ability to play different roles because of the small number of electronics available to the RCX brick and the limited number of input / output channels on the brick itself (both limited to three). Considering this and the previous reasoning, the RCX was given the roles of disruption and nest acquisition. Essentially, the RCX bot would, as quickly as possible, knock over all of the toilet paper rolls in the arena, and then acquire the central scoring nest, hoisting it into the air so as to prevent the other team from using it as a method of scoring. At the same time, the bot would knock the foam ball initially inside the nest towards our side of the arena, probably preventing the other team from acquiring the ball and possibly scoring points. All of these goals appear reasonably feasible because all of the locations the bot would travel to can be reached via black electric tape. The disruption role seemed especially desireable because videos from last year's competing teams locked onto vertical toilet paper rolls to collect ping pong balls. Conceivably, the bots would not be equipped or programmed to deal with the collection of horizontal tubes or stray balls. The Handybot would primarily be responsible for scoring. Alternatively, if the RCX bot was eliminated from the strategy, it would also have a means of knocking toilet paper rolls over itself. This could be as easy as having a forward edge that would contact vertical TP rolls high enough to knock them over simply by moving into them. The actual mechanics of the bot would operate in a fashion similar to the lego vacuum shown in class: either through forward motion or an independent motor, the bot would sweep ping pong balls off the ground into an angled chute. Once in the chute, rotating teeth / conveyer belt mechanisms would raise it higher into a storage bin. After sweeping the area, the bot would deposit its collection of ping pong balls into scoring position. This design was attractive for several reasons:
An image of a trash collecting boat that uses the same idea as we are proposing for our handyboard robot. (Found at www.alphaboats.com) PerspectivesThe Botball competition takes place in a fixed arena and is fast based (90 second rounds). Our robot must be as efficient as possible at navigating this fixed arena. A simple robot insect [2], while necessarily less complex than a traditionally decomposed robot, may not necessarily be efficient at Botball.Potential fields models like the one used in [5] would require better knowledge of global state than our sensors on the Botball robots would be able to detect, as well as requiring more memory than we are likely to have. Localization will also have to be done roughly, as map-based state tree [6] would require a more restricted state space and Monte Carlo [7] methods would require more memory and processing power than will be available on our robots. Documentation
References
|