6.270 Team 27: Strategy

Home    History    Strategy    Pictures

 

Robot Design

by Andy Hurwich

Our robot was designed with a differential drive with a gear ratio of 125:1.  A shaft encoder on each gear box and gyroscope helped the robot drive straight and make accurate turns.  The gearboxes were built vertically to conserve space for an area to hold the balls.  The ball holding area took up the front half of the robot.  The balls were captured by a one-way gate that was powered by a motor to allow balls to be let out when necessary.  Inside the ball holding area was a bar that rested on two smooth tracks that was capable of pushing all the balls out of the holding area to vote them if necessary.  Three light sensors were placed on the robot--on the front left, front right, and back right--to allow the robot to orient itself in the beginning of each round.

 

Strategy

by Ryan Dean

The design of our robot is centered upon collecting as many balls as possible of one color.  We first figure out our orientation, turn towards the back wall and then put the two balls of each color that are located next to the starting position into our scoring area.  That way we will have two points no matter what.  From there our robot will go to one side of the board where all the balls of one color are located, the direction will be opposite of the direction that the other robot chooses to go.  We want to pick up as many of them as possible within the first 45 seconds or so.  In the last 15 seconds we plan to either score those balls or vote them all.  If the color we are collecting has more votes then we will drive our entire robot to one of our scoring areas in the corner of the board.  If the color of balls we are collecting are losing, which they most likely will be if we are doing a good job collecting all a majority of the balls of that color, then we will vote all the balls we have in the very end in an attempt to give the other team negative points.

Our plan should work best against robots that are trying to score a lot of points of one color without interfering with us too much because our plan should be able to get them a lot of negative points.  Contact with the other robot should not affect our plan once we have picked up enough balls, but in the event of a collision our robot will be strong enough to survive.  We think that the other robots will just be trying to score points at the end leaving us free to drive to a corner or a voting area.

We plan to minimize errors by keeping the robots actions fairly simple.  We think that this should ensure a reliable robot, one that can go straight and turn within a small error margin.  We also plan on minimizing interference by the opposing robot by deciding which color balls to go after only after the other robot has first moved.  If the other robot starts moving to one side then we will try to pick up the balls from the other side of the board.   

Steps 1 through 7 are self-explanatory.  A few notes though: Step 2 simply indicates backing up, whereas step  indicates turning around and the going forward.  Step 1 & 2 together score the 2 green and 2 red balls.  The 3 through 6 are steps to capture as many balls of one color as possible.  Step 7 returns you to the voting are, so during the last few seconds, you can decide whether to vote the balls or turn around and score them in your scoring area. 

 

Coding

by Rick Pernikoff

We decided to keep the robot's functions relatively simple, to perform basically the bare essential tasks.  The majority of the coding time went into getting the robot to move in a straight line and to turn to a desired angle, with the help of the sensors.  The other basics tasks were simple to code, including the bar push to release the balls, and the gate open and close functions.  They just required timing measurements and estimations.  The basic strategy was just a sequence of going straight until hitting a wall, and turning to the desired angle.  We realized that although there are four cases (go left or right, and if white team or if black team), there are only two distinct sets of motion. 

To turn to a desired angle in place, we tried to use the shaft encoders, but that proved too difficult and no better than without them.  Instead we just used the gyroscope, and told the robot to turn until the angle was reached. 

To go straight was a much more difficult task.  After trying to only use shaft encoders to speed up and down the individual motors, we gave up because there was too much error.  Instead we incorporated the gyro into the going straight process.  The shaft encoders by themselves speed up or slow down the individual motors until the encoder readings are somewhat the same, meaning each wheel is going the same distance.  But there was too much error, so I put an check within the goStraight function to go back to the original angle when the goStraight function was first started, if it ever turns more than 2 degrees. 

Once these functions became reliable it was a matter of strategy to program the actions of the robot.  Turning to the back wall simply used the 3 light sensors to figure out the initial position on the black and white squares, and then the gyro aids in the turn. 

 

Results & Conclusions

by Andy Hurwich

In the first round of the competition, the robot was on the black side oriented facing the back wall towards our scoring area.  Unfortunately, when the match started it immediately turned 30 degrees to the right and stalled out, doing nothing for the remainder of the match.

In the second round, our robot was on the black side facing the red balls.  When the match started, it turned 70 degrees to the right, and stalled again.  Twenty seconds later it moved forward until it hit the wall, pushing a green ball into our scoring area in the process.  After hitting the wall it did nothing.

The robot made two errors during the first round.  The first was not realizing which way on the board it was facing, and the second was stalling out.  The first was probably the result of a faulty light sensor.  The code that told the robot which way to turn based on the readings on the light sensors was thoroughly tested prior to the competition, and worked perfectly.  The light sensor may have failed to properly read the board because the amount of light on the board during the competition was different from the amount of light during testing.  It could also have resulted from us moving the light sensor because the robot was slightly too wide, and we didn't place the sensor at the same height.  The second error was stalling after only completing a partial turn.  This was caused by the code that measured the turns: slowly powered down the motors so the robot didn't overshoot the turn as the robot got closer to the end of the turn.  We coded it so that the robot turned well on our floor, which we thought had similar friction as the board.  Apparently the board had more friction, and the motors were powered too far down to turn the robot.

In the second round, the robot stalled again, and for the same reason as in the first round.  It got further in the turn the second time, and eventually reached the point where it decided that it had completed the turn well enough, and drove forward, as was directed in the code.  Because it didn't complete the 90 degree turn, it didn't knock all four balls into our scoring area; it just knocked in one green ball.  If green was the randomly selected color designated ahead in the beginning, we would have scored two points and won, but it wasn't, and we lost.