Report 3: Prototype Construction

Back to main page

Revised Timeline for Project 2 (as of 2/25/04)

ooo: New items
ooo: Changed / removed items
  • Week 1:
    • Finalize ideas for the "vacuum bot" including details of sensor configuration, how to dock with the scoring baskets, and brainstorm how it will navigate the arena.
    • Finalize the RCX robot concept of the "nest flipper" including determining how to lift the nest so that the ball is free, and resolving any potential problems with starting the game.
    • Build the first prototypes of both robots.
    • Revise strategy and design based on findings with Vacuum bot (reiterate above steps for new Grabber bot)
  • Week 2:
    • Continue construction on Grabber bot
    • Start development of initial code for basic movement and the functions specific to each robot (managing the conveyor belt and nest flipping).
    • Improve prototypes as any structural flaws become apparent.
    • Paint arena.
  • Week 3:
    • Start development of initial code for basic movement and grabber function validation
    • Continue development of the initial behavioral software.
    • Continue to improve prototypes as necessary.

Observations from "Vacuum Bot"



We decided to abandon the two-robot vacuum bot concept because it became apparent that it would not be competitive. The largest problem with the previous strategy is that the use of the RCX bot was based on it being able to quickly steal the nest and knock over all of the toilet paper rolls. However, the motors available for use on the RCX were not up to the task. In particular, in order to gear the wheels to have enough torque to move the nest required making the bot very slow, defeating its intention of being able to sabotage the other side before it could pick up any of its TP rolls. The sensory capabilities on the RCX would be inadequate to reliably knock over the TP rolls without using the nest. As the only sensory capability of the RCX would be line-following, it wouldn't be able to see the TP rolls, and the added bulk of the nest was needed to be able to wreak havoc despite imprecise positioning. Therefore, while the RCX could conceivably fulfill one of its two original roles, if it only knocked over TP rolls we would sacrifice defense of the foam ball, and if it did not knock over TP rolls our vacuum design would be less efficient than a traditional grabber bot. There were also logistical difficulties that would need to be worked out in order to have the two robots not step on each other's toes.

Another big problem with our previous strategy is that it was essentially defensive. While playing defensively may be a plus in head-to-head matches, the seeding rounds require being able to score a lot of points with no opposing team and also count toward final reckonings. For this reason, offensive play is much more important in the tournament. While a vacuum-style bot would be unique, it was less efficient since it picked up single ping pong balls, while other bots picked up three at a time. It also appeared to be more difficult to implement than a grabber-based robot. It is easier to grab onto something than to precisely align so that it can be conveyored in. The conveyor is fairly large, and can not be folded up like a grabber arm capable of vertical motion. The conventional grabber arm can be folded into a compact volume, whereas the space sacrificed by using a conveyer chute could not be justified without a fully functional RCX.

Strategy for Grabber Bot

As described in the previous section, upon construction of initial prototypes we found our previous design and scoring strategy to be impractical. To simply match getting the foam ball in a team (white/black) basket we would have to collect half or all our color ping-pong balls into our team basket, or 3 in a green basket. If the opposite team scored the foam ball into their green basket, that would leave us having to collect all of our colored ping-pong balls into our team basket or half of them into a green basket. Considering that half of our ping-pong balls are on our side and the other half are on the opposite team.s side, it.s optimistic to assume that we would have been able to collect half of our color ping-pong balls, making a win highly improbable if the opponent had the ability to score with both the foam ball and the ping-pong balls.

Our new strategy involves exactly the kind of opponent that would have utterly defeated our first concept. The key principle of the new design is a multi-purpose arm that will be able to acquire the foam ball and toilet paper rolls containing ping-pong balls, as well as drag the green baskets around. As soon as the game begins our robot will race out to where the nest should be and, using the CMU cam and sonar sensors, pick up the foam ball, hopefully faster than the opponent. Once the foam ball is grasped, the robot will locate our green basket and deposit the ball there. Since not much else other than the foam ball will fit into the basket, we can drag the basket off into our starting corner where we can leave some sort of locking mechanism that will prevent other teams from moving the basket to their side. This securing of the basket would be optional. For example, if we observed that the other team does not actively go after its opponent's green basket, then we could switch off the securing option and not waste any time on it. After depositing the foam ball in the green basket (50 points), the robot will return to the center of the arena and grab any TP rolls of our color that are still standing, deposit their contents into a rear storage compartment, and then depending on the time remaining, either deposit the collected balls into our team color basket (5 points each), or attempt to drag the green basket on the opponent's side to ours and deposit the balls there (10 points each). The additional advantages of stealing the opponent's green basket will be that, if it is on our side, he will not get points for anything that is in it, and if he happened to snatch the foam ball first and place it inside his green basket, we would end up getting the points for it.

Justifications for New Bot

The new robot will have a number of advantages over our old design. It is a single robot, and so we do not have the same space constraints that the old two-robot strategy used. This also means we can use both the HandyBoard and RCX board on one robot, which gives us more sensors and motors to use. The new robot also has greater flexibility, including manipulating the foam ball, toilet paper rolls, ping-pong balls and the green basket. This will provide us with more scoring opportunities than the old design had.

From a design and programming standpoint, the arm should offer more of a challenge in designing and using. Our new strategy will probably also require more variety of programming, as opposed to a simple wander task and docking with the green basket, which the old one had. We now have to acquire the foam ball, put it in the green basket on our side; acquire ping-pong balls from the toilet paper rolls, and take the opponent's green basket. Hopefully this will still be feasible in our time-frame.

General Design Spec and Diagram for Bot

Below is an image depicting the general placement and usage of the sensors on the HB Bot:


  1. Micro Motor: Used for rotating shelf (for toilet paper manipulation)
  2. Servo #1: Used for opening and closing gripper
  3. Servo #2: Used for raising and lowering gripper arm
  4. Servo #4: Used for rotating CMUcam
  5. CMUCam: Used for spotting colored nests and foam ball
  6. Upper Rear Bump Sensors (RCX): Used for docking contact to emptying ball bin
  7. Lower Read Bumpb Sensors (HB): Used for rear contact detection
  8. Motors #1 + #2 (HB): Used for wheel control
  9. Tophat Sensor #1 (HB): Used for tape detection
  10. Sonar (HB): Used for nest, basket ranging
  11. Forward Bump Sensors (HB): Used for nest ranging, forward contact detection
  12. Handyboard
  13. RCX Brick

Perspectives

The 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. Due to our robot's low degrees of freedom and limited environment, explicit declarative programming of behaviors should suffice. Learning methods based on training data [8], while useful for more complex domains, would not work well for us as we have no easy way of acquiring such data.

Documentation

References


0. Collegiate Botball Rules - 2004
1. Horswill, Ian The Polly System.
2. Brooks, Rodney Achieving Artificial Intelligence Through Building Blocks, MIT AI LAB, Memo 889, May, 1986.
3. Botball Kit Part List.
4. Handy Board and Interactive C Documentation.
5. Vaughn, Richard et al. Experiments in Automatic Flock Control. Publication details unknown.
6. Nourbakhsh, Illah et al. Dervish: An Office Navigating Robot. AI Magazine, Summer 1995, pp. 53-60.
7. Dellaert, Frank et al. Monte Carlo Localization for Mobile Robots. Publication details unknown.
8. Drumwright, Evan et al. Exemplar-Based Primitives for Humanoid Movement Classification and Control. IEEE 2004 Conference on Robotics and Automation.