Team Twelve/Final Paper

Revision as of 06:02, 4 February 2013

Despite our initial MechE ignorance, we Nomkeys 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.

And we got to know each other very well:

• Melody kept us all organized with her checklists and, by continuous questioning, made sure nothing would go wrong.
• Roxana saved us by staying sane and jumping to action when things were falling apart during pineapple time.
• Holden (...)
• David "entertained" us with his pessimistic "humor" and stayed cool while coding under pressure.

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. Quick note of advice. You'll have to secure things to poles. We ended up keying the rod to make one side flat and then attaching parts with set screws. This is pretty easy to make at Edgerton.

• 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 Seeding. 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 were quickly dissuaded by the staff, who told us that the winning design from last year was an Archimedes Screw

Final design: Archimedes Screw. We used a lot of different wires for making the screw, but we eventually settled on Steel welding rod (given to us by kind people at Central Machine Shop. Roxana is good at making friends.) We tried different widths of aluminum welding rod but it was too malleable.

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 would only go for the button again after 20 seconds.)

Hermes's basic Actions consisted of the following (which are self-explanatory)

• GoForward
• MaxForward
• GoBack
• TurnLeft
• TurnRight
• ForwardToTarget (e.g. ball, button, wall, or pyramid)
• DoNothing
• ReleaseBalls

Hermes's instincts are to

• turn around to look for balls and other targets,
• if she saw an appropriate target, he would go for it, and
• if she was stuck, back up.

It is not difficult to turn these into a list of States (associated actions in parentheses):

• Wander (GoForward)
• AvoidWall (TurnLeft or TurnRight) - try to swerve away from a wall
• TurnAndLook (TurnLeft of TurnRight)
• ApproachBall (ForwardToTarget)
• ApproachButton (ForwardToTarget)
• ApproachWall (ForwardToTarget)
• ApproachPyramid (ForwardToTarget)
• Stuck (GoBack)
• Charge (MaxForward) - charge towards a target
• Pause (DoNothing) - once she has a target centered, he pauses to allow the vision system to process the location of the target
• Stop (DoNothing) - automatically triggered after 3 minutes.
• Score (ReleaseBalls) - open the hopper door and close it several times, to shake the balls out

Finding the right transitions took trial and error. Each state has a list of transitions, with some taking higher priority than others. I'll describe a typical example below, and refer the reader to the (really complicated state diagram which I'll attach soon) for details.

Stuck detection was essential. It would not do for Hermes to get stuck in any particular state, so I instituted a timeout for each state. For most states, Hermes would query wrapper.stuck() which would return (x,y) where 0<=x,y<=3, and x, y represent how stuck the left and right side are, respectively, from the readings of the 2 IR sensors and the bump sensor (bump sensor pressed representing maximum stuckness).

• Wander: In order of priority,
  • If stuckness is >=2 on either side, Stuck!
  • If Hermes sees a target, TurnAndLook to center it.
  • If stuckness is >=1 on either side, AvoidWall (swerve before it actually gets stuck).
  • If 5 seconds have passed, TurnAndLook
  • Else, keep wandering.

Some special notes on the states:

• the TurnAndLook state: Hermes remembers IR values as it turns. If it turns a certain amount and doesn't see a ball, then it turns back until it finds approximately the minimum IR value and Wanders in that direction. This ensures that it goes towards an open space.
• the ApproachXXX state: It calls ForwardToTarget with the right target argument. ForwardToTarget uses a PID (proportional-integral-derivative) controller with constants
  • K_p=.8 motor speed/degree
  • K_i=.1 motor speed/degree*s
  • K_d=.1 motor speed*s/degree

VisionSystem provides the coordinates of the center of the target. When the target was close (i.e. its y-coordinate was low), Hermes would forget about PID and just Charge.

• Charge: When charging the wall or pyramid, Hermes needed to know when it was aligned so it could release balls. To make up for possible malfunctioning of bump sensors (they tended to get banged around), I had multiple criteria. For instance, it would release when both bump sensors were pressed, or one was pressed and 5 seconds had passed, or IR values were within a certain range.

At first the targets were set to the right-color ball. After 2 minutes were up, a timer automatically changed the target to the goals. If Hermes scored successfully, the target was changed again to balls.

Vision System (David)

Debugging

Python allocates time to its threads HORRIBLY. At the beginning we ran the state machine, sensor modules, and VisionSystem in separate threads. However, this meant that our state machine updated very slowly---once per second---(even with time.sleep's) so we made two fixes:

• Changed VisionSystem to a Process.
• De-threaded all the sensors.

After this Hermes responded much faster.

Overall performance

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

Roxana:

• 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".

Melody:

• Split up the work at the beginning! Like, 2 builders, 2 programmers. Also, make a schedule and try to keep to it, so that you accomplish a bit of something every day.
• Get Edgerton access. For almost 3 weeks, we only had one person on our team who had Edgerton access, which made things super duper slow, on the building side. But there were no other training sessions. I ended up just talking to Mark (Edgerton manager) and he let me work there, even though I wasn't officially trained.
• Find someone with lasercutting access. It'll be useful when your acrylic pieces break...
• Try to finish a CAD model of your robot as early as possible.
• Also, if you don't know what to do, just ask the TAs. For us, especially at the beginning, we felt super lost and were a bit intimidated by them. But they're super helpful and really nice people, and we got to know some of them pretty well.
• FINALIZE YOUR STRATEGY. Our team somehow didn't decide that we only wanted to score over the wall / lower level of pyramid until the very, very end, which made building very stressful. Know what you want to do. Also, even if you don't have mechanical ability, don't be afraid to aim high (literally, in our case). You'll figure things out! Also, mechEs on other teams are especially nice and helpful when you have questions.