Team Twelve/Final Paper

Revision as of 05:06, 4 February 2013

Despite our initial MechE ignorance, we Team 12 made it through Maslab with a robot who scored in the final competition. Our success would be impossible without the hard work of every one of our teammates:

• Roxana and Melody planned and built the robot's body. They crash-coursed themselves on designing and machining: Melody CAD'ed all the parts, Roxana made numerous trips to Edgarton and CSAIL to build the brackets, screw, hopper, bearings, ramp, and other attachments, and laser cut the three layers. Together they assembled and reassembled the robot many times.
• Holden gave the robot brains. He programmed and tested the state machine that tells the robot to explore, go after balls, and score.
• David gave the robot sight. He programmed the robot to recognize yummy round red and green things, the blue tape marking the boundaries of its world, and the yellow walls and purple pyramid.

Overall Strategy

At first our goal was to score balls in the pyramid.

One interesting thing to note: balls thrown over the perimeter of the field does not count as negative points. It would be unfortunate, however. In the end, throwing the balls over any wall would have been advantageous.

Mechanical design and sensors (Roxana and Melody)

Ball Possession: Essential Components

Last year, the rubber band roller, though not common amongst the teams, showed quick and easy success. We made a completely functional one for our Peggy (pegbot), and won Mock 1 by being excellent at collecting balls. We used a kit motor with a crude but quick motor mount to secure the roller to Peggy's wooden walls.

RUBBER BAND ROLLER - We decided to move ahead with CAD'ing the wheels for laser cutting out of acrylic. The staff had a helpful SLDWRKS file that we altered slightly (made the ridges deeper to be able to use thicker rubber bands). To keep pressure on the wheels to oppose the force of the rubber bands, we used a keyed rod to go through the centerholes, and attached shaft collars to the rubber band wheels that contained set screws.

RAMP - We also had a ramp along the bottom layer of our robot, to direct balls into the mouth of the helix. That is, the ramp had pieces of cardboard that acted as walls. It started at the bottom of the rubber band roller and angled upwards in a semicircle arc until the maximum height that balls could go up. It then slanted downwards slowly to give the ball some momentum to end up in the perfect pick-up spot for the helix.

ROBOT DESIGN - All of our robot prototypes had very low robot bases, only .25" off the ground or so. This way, we did not need the ramp to collect balls (note: not bring them to the hopper, just collect them), and this way we won Seating. At some point, Hermes ate 6 balls and kept them in "herm" stomach. Goes to show: crude ball collection, paired with dependable code, can get you an easy win before the final competition.

Upwards Transport in the Robot: the Archimedes Screw

We understood that we need an internal upwards-carrying mechanism in the robot to score. The lowest scoring point was 6", so we needed a mechanism to move a ball up at least that high.

1st IDEA: PULLEY + CONVEYOR BELT - At first, we wanted to make some simple conveyor belt with sturdy metal parts which could figuratively "scrape" along the bottom of the ramp and draw up balls. We would be able to

Robot Motion: Trying out Gears, Not using them

We had a pretty simple yet sweet gear setup on our second acrylic prototype. Thanks to Mark and a beautiful lathe machine, we made a brass shaft to insert into the walls to let the middle gear spin freely. Gear count: a small bevel blue-threaded on a kit motor coupler, at 90 degrees with a freely spinning bevel on the wall, sort of randomly placed. This was in line with a white gear (provided) adapted with a set screw fit onto a .25" keyed shaft that also attached to the blue rubber wheels provided.

In the end, we dropped the gears because of stripping bevels, and the tiny bevel slowly falling off the motor shaft coupler. We remade our lower walls to accommodate large motors for high torque for the wheels. This caused "running into walls with happy abandon" to become a dangerous occurrence. Some advice: don't use gears unless you know how to.

We also had a caster I randomly found in Pappalardo lab scrounging for cotter pins, and it was a very good size for the back of the robot, however keeping it tilted forward slightly. We figured the center of mass of the robot was the 12V battery and the laptop battery, which would be placed somewhere along the back of the robot anyway, so we used it in the back.

Sensors: On How many, Placement, and Redoing the EE way too many times

Upward Motion

We had a conveyor/pulley belt idea at first. Here are some sketches:[[File:]]

However, after our with-the-staff meeting, we decided to use the Archimedes screw as our ball-lifting mechanism. Attach CADs?

Software design

All our code is available on the github repository (link). We rely on the staff code for the arduino firmware. Here is an overview:

• main.py: starts the state machine.
• actions.py: defines the basic actions the robot can take, such as moving forwards, turning left, or releasing balls.
• states.py: defines all possible states the robot can be in. (See the next section for an explanation.)
• wrapper.py: a class that encompasses all current information the robot has. It provides communication with the arduino, so for instance has all the sensor readings; it logs the current time.
• VisionSystem.py: processes and filters images, finding locations of targets and passes them to wrapper.
• constants.py: defines constants such as motor speeds. Putting all the constants in a separate file was useful when we wanted to change/calibrate on the fly.
• mapper.py: outputs a local map given input from the camera. We did not use this in the final competition because we did not have time to get it working.

(The other files are various tests, and are unimportant.)

State Machine (Holden)

I decided to program Hermes's brain as a state machine. This means that at every instance in time (s)he has a well-defined state such as Wander, ApproachBall, or Score, and that she transitions to the next state based on his/her sensor readings (does (s)he see a ball? is the wall close?).

I used a state machine because

• it was simple, and
• it worked.

Though a state machine is conceptually simple, it had served many winning teams in the past. The easy part is creating the state machine architecture and defining the states. The hard part is determining the right transitions between the states: after what time should Hermes give up on a ball? Under what combination of sensor readings should Hermes realize that (s)he is stuck? To program the right transitions I had to go back and forth many times between testing and programming, because it is impossible to forsee all the circumstances the robot can be caught in.

Implementation Details

I defined a superclass called State. Each State has

• an Action associated with it,
• and a "stopfunction."

Furthermore, each State passed a Wrapper object to the next state.

The idea was that States represented an ***intention*** while Actions represented a simple ***command*** to the motors and servos. So for instance, the Wander state represents the robot going forward to explore an open space, and the associated action is simply GoForward, which turns both motors forward.

The stopfunction for a state, by examining the Wrapper object, returned the next state to transition to. For instance, if upon querying the wrapper it found both bump sensors to be pressed, it would return the "Stuck" state. The stopfunction returns 0 if the robot should not transition yet.

The run method in State (ex. Wander) would loop the Action corresponding to the state (ex. GoForward), calling stopfunction in each loop to see if it should transition. If so, the state machine transitions to the next state.

States and Transitions

Our strategy was to

• collect balls in the first 2 minutes of the game, and
• find a yellow wall to score in the last minute.

If Hermes didn't see any balls, but saw the cyan button, she would go for that, and if he didn't find a yellow wall but time was short and she saw the purple pyramid, he would go for that.

Hermes's basic Actions

Vision System (David)

Debugging

Overall performance - all

Hermes stuffed hermself with balls, and sometimes banged the button to get more balls. During seeding, (s)he was the most energetic of all the robots, ramming into walls and turning the pyramid around for several revolutions.

After seeding, Hermes grew out of her "bumping-into-walls" phase, and learned to score. We got 70 points in our match against the Mengineers,

• 60 points from collecting 4 balls and depositing them into the purple pyramid, and
• 10 points from collecting 2 more balls.

Conclusions/suggestions for future teams - all! we can separate this by person

R:

• Organize your electronics FROM THE START. This is compulsory. Weak connections caused our robot to not really be able to run our very first match (Right motor wires were not in motor controller all the way).

• Try to make stuff/prototypes early. Anything. Make Anything Early.

• MAYBE HAVE A MECHE ON YOUR TEAM?? Although I can't say it went badly. If you've never done this stuff before, keep it all really simple. It was awesome. Even if you think you might fail at stuff, keep going. Ask for help.

• Huge thanks to all the Maslab Staff (IHOP ANYONE???), Mark B. (and the rest of Edgerton staff), Ron W. (of CSAIL), and Richard B. (and the rest of the CMS) for all the super mega awesome help. Each of you should get to choose between Donuts and Chocolate.

• Super Mega Foxy Awesome Hot Teams:
  • Thanks to HexnetLLC (team 1) ([1]) for laser cutting our stuff the first two times and being generally wonderfully supportive and helpful.
  • Thanks to Janky Woebot (team 7) ([2]) for keeping us oddly reassured and relaxed (whenever I soldered something, Melody was always laughing with you guys ^_^). Your robot's helix moved so fast...almost as fast as my heart fell for it.
  • And no less thanks to all the other teams for being friendly all through this "competition".