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
- 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
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
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:
- Micro Motor: Used for rotating shelf (for toilet paper manipulation)
- Servo #1: Used for opening and closing gripper
- Servo #2: Used for raising and lowering gripper arm
- Servo #4: Used for rotating CMUcam
- CMUCam: Used for spotting colored nests and foam ball
- Upper Rear Bump Sensors (RCX): Used for docking contact to emptying ball bin
- Lower Read Bumpb Sensors (HB): Used for rear contact detection
- Motors #1 + #2 (HB): Used for wheel control
- Tophat Sensor #1 (HB): Used for tape detection
- Sonar (HB): Used for nest, basket ranging
- Forward Bump Sensors (HB): Used for nest ranging, forward contact detection
- RCX Brick
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 , while necessarily less
complex than a traditionally decomposed robot, may not necessarily be
efficient at Botball.
Potential fields models like the one used in  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  would require a more restricted state space and
Monte Carlo  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 , while useful for more complex domains, would not work well for us as
we have no easy way of acquiring such data.
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
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
8. Drumwright, Evan et al. Exemplar-Based Primitives for
Humanoid Movement Classification and Control. IEEE 2004 Conference
on Robotics and Automation.