Team One/Final Paper

From Maslab 2013
Jump to: navigation, search

Contents

Maslab 2013 Team 1 Final Paper

Team 1:

  • Daniel Gonzalez
  • Nanu Roitman
  • Rodrigo Gomes
  • Tyler Hamer

Overall Strategy

Our group focused on first finalizing the mechanical design and building a robot that would behave consistently and do what we told it to do. After that was done, we programmed it to try and solve the proposed challenge (pick up balls and drop them in the scoring tower or over a wall to the other playing field).

We managed to achieve our goals mechanically: the robot behaved consistently and had the ability to do everything required by the presented challenges: it could score over walls, detect and pick up balls reliably and it was capable of locating itself with minimal error due to very precise encoders. Our low-level strategy relied a lot on encoders, since we used them to guide controllers that made the robot move straight and rotate in place, and also had controllers to tell the robot to go to way-points (locations relative to the robot's position and angle), which worked very well.

However, the encoders turned out to be one of our biggest problems, and the fact that we relied on them so much made us lose a lot of time getting them to work correctly and figuring out why they didn't work so well. It turned out that applying large amounts of force to the motors would cause the encoders to not work completely (they would start not counting or counting backwards – we believe it was because of the large amount of current drawn by the motor turning it into a powerful electromagnet, but we're not sure), which was an issue when the robot got stuck shortly if it was running fast (our ultimate solution was to program the robot to avoid collisions a lot – which we managed to do very successfully – and force it to move slowly).

As for higher level strategy, originally we had planned to use a sophisticated strategy for the robot: have it represent its state according to beliefs he had about the world (such as how long before the round ended, how many balls the robot was holding, …) and cache a policy that would translate the robot's state into an action (that policy would be precomputed through a recursive strategy that would try to find a good policy by looking at some reward metric assigned to actions and maximizing the sum of the rewards).

The robot was capable of doing mapping and planning, and that allows us to give it a large set of useful actions and capabilities (such as remembering the position of a scoring wall and planning to go there, or create plans that maximize visiting unexplored plans). In the end, we barely used those capabilities (mapping was used to make the robot capable of knowing whether a ball was reachable and planning was used to go to unexplored places) because of time constraints. We were unable to program enough actions and devise a good state description for the robot, and ended up implementing a simple strategy: follow walls until the robot either sees a ball or a scoring wall, and when that happens head for the ball/scoring wall (the second only in case the robot believes it is holding a ball or there are less than 30 seconds left), and pick it up/score.

This simple strategy was effective in theory, but due to a lack of time for testing, it ended up failing due to implementation details that were overlooked. The biggest problems we had with it were how long it took the robot to compute that a ball could be reached (sometimes the robot would get stuck trying to reach an “unreachable” ball – to close to the wall – so we used mapping to make it possible for the robot to know to ignore that ball, but that took some time to compute and we didn't account for that, making the robot lose track of the ball before it started heading for it), and the “sloppy” way how the scoring mechanism was implemented (it would drive towards the scoring wall, but assume that the first wall it found was the scoring wall and would drop the balls over that wall – what ended up happening was the robot stopping “prematurely” on its way to the scoring wall, and putting balls over other walls, thus losing points).

For testing the programming of the robot, we developed a simulator close to the end of Maslab, and that offered an advantage, but it was unfortunately too late for it to make a big difference, and we also had to test in the real robot, since the simulator made many assumptions only approximately correct.

Overall, we are very proud of what we achieved, because the robot behaves very well, and wished only to have had more time to test the higher level strategy.

Mechanical Design and Sensors

Mechanical Design

Tallahassee’s was designed mechanically from the bottom up. First Tallahassee’s drive train was designed. Secondly we designed the mechanism to pick up the balls, referred to as the ball sweeper. This was followed by the ball raiser and the overall chassis design. Finally the hopper, the mechanism to spit out balls and a ramp were designed at the top of the robot.

Drive Train

In the beginning, we decided that we wanted to design a robot as professionally as possible. We wanted to put out the best robot without cutting any corners. Therefore, we chose to use 4,000 counters per revolution encoded Pittman motors that Dan had acquired at MITER’s Swapfester earlier in the year. By using encoded motors, this would allow Tallahassee to both drive straight and turn a desired amount of degrees.

Pittman 9234E665-R1.jpg

Brand: Pittman

Model: 9234E665-R1

Type: Brushless + Encoder

K_V: 340 rev/(V∙min)

Encoder Precision: 4000 counts/rev


However, the Pittman motors had a KV of 340 rev/(V∙min) so they needed to be geared down. To keep the robot as simple as possible, we were already using the Banebot wheels supplied by lab because they came with adapters to attach the wheels to drive shafts. These wheels had a diameter of 3-7/8 in. Since we had a limited budget of $100 of our own money, we chose to use the gears available in lab. Limited by the white gears available in lab, we settled on a gear ratio of 13.5:1. This would give our robot a top speed of 1.551m/s using these Banebot wheels and the Pittman motor run at 12V.

Banebot wheel.jpg Gearbox.jpg

Two of these drive wheels and their gearboxes were mounted in the bottom of Tallahassee. The drive wheels were mounted such that their centers lined up with the center of Tallahassee’s base. This is often known as “Center Wheel Drive” and provides the robot with a zero turn radius. A zero turn radius is desirable for it decouples translational and rotational movement for the robot, thus simplifying planning. In addition, there was a caster wheel in the back of the robot to serve as a third point of contact to make the robot level. NOTE: With the foam tiles, large ball casters are needed because small caster balls get stuck between tiles.

Ball Sweeper

From looking at past designs, we decided to use a rubber band sweeper to enable Tallahassee to pick up balls. The parts the held the rubber bands were laser cut acrylic pieces that had the diameter of the ball, in this case 2.5 in. In order to prevent jamming, the ramp needed to be behind the sweeper because the sweeper has to push the ball up onto the ramp. In addition, the lowest part of the ramp had to be at least 3/16 in above the ground to prevent it from catching on the mat. To optimize the sweeper to pick up balls, we placed the point where the rubber bands contact the ball at 75% of the ball's total height. Therefore the ramp had to be angled and positioned such that when the ball was either on the ground or ramp, the sweeper contacted the ball at 75% of the ball's total height.

Right Sweeper Mount.JPG Sweeper Assembly.JPG

Ball Raiser

For the mechanism to lift the balls, we wanted something extremely compact. We decided that a helical structure would allow this. At first, we wanted to build a helical ramp and push the ball up the helical ramp (similar to a parking garage). However, we could not figure how to build a helical ramp out of sheet metal. Hence, we decided to use the helix to push the ball upward instead of pushing the ball up the helix.

Hence, we decided to build an Archimedes screw to push the ball up a two bar "tube". To do this, we needed to build a screw such that it would contact the ball and push it into two vertical linkages. Since the ball could not pass through the linkages, as the screw would turn, it would move upward. To ideally do this, the screw should have a diameter about half of the ball. However, we messed up in initial calculations and made the screw have the diameter of the ball. As a result, the ball would fall into the screw. This is not a huge problem for moving the linkages the ball is pushed into closer, fixes it. However, it is much harder to make the ball leave the screw.

In the end, our screw had a pitch of 4in and a diameter of 3.5 in. To make it, we bent 1/8 in. steel around a piece of 3.5 in diameter aluminum. However, when you let go of the steel when bending, it springs out to a large diameter. To fix this, you have to either bend it around a smaller diameter pipe and let the steel spring out to the right diameter, or heat treat it when bending it. We took the second option and heated the steel with a blow torch when bending it. Then we welded supports to it to hold the steel helix in position with the right pitch and diameter.

Lastly, the helix was powered by a continuous rotation servo at the top of the robot.

Raiser.JPG 20130127 003950.jpg 20130127 055624.jpg

Chassis

We decided to make the chassis out of Medium Density Fiber Board (MDF). MDF can be bought at Home Depot and has several advantages. First, MDF is not brittle and won't break like acrylic does. In addition, it can be laser cut which is useful since the design changed a lot.

We decided to make the chassis modular. In order to do this, we made a separate platform of each component. This way, if something needed to be taken off and fixed, the whole robot did not need to be taken apart. The bottom two layers held the drive motors, caster, and the ball sweeper. Layer 3 held the camera and the sensors. Layer 4 held the circuit boards. Above layer 4 sat the hopper to hold the balls.

Platform1.JPG Platform2.JPG Platform3.JPG Platform4.JPG Standoff 1-2.JPG

In addition, we layer cut the standoffs to separate platforms. We did this to increase manufacturing speed, which greatly helped. In order to laser cut standoffs, we designed the standoffs so that they could connect to the layers using slots and tabs and t-nutting.

Hopper

The Hopper was designed to carry as many balls as possible. Thus, we designed the hopper such that when balls came out of the screw, they could pile up two layers high and stay in the hopper. For building the hopper, we originally wanted to use sheet metal, but could not find long enough pieces. In the end, we ended up using a flexible plastic we found. It was not acrylic. We believe it was polycarbonate. Since it was probably polycarbonate, we had to cut it with a band saw since laser cutting polycarbonate is toxic. DO NOT LASER CUT PLASTICS YOU DO NOT KNOW THE COMPOSITION OF!

Ball Spitter & Ramp

Lastly, to release the balls from the hopper, we decided to use both a ramp and a ball spitter. We did this because it enabled use to lower the ramp, but not to release all the balls at once. This gave us the option to score in the pyramid, but also throw a ball over to the other side if needed. The ball spitter is construsted in the same fashion as the ball sweeper. The ramp was constructed out of sheet metal and powered by a servo.

Hopper Assembly.JPG

Sensors

The robot has very complete sensing capabilities:

  • Encoders allowed the robot to know where it was, with 1 or 2 inches of error, even after 3 minutes (the encoders were good enough that an IMU was not necessary);
  • Distance sensors an array of 5 Infra-Red distance sensors, exhaustively calibrated, at the angles of -90,-45,0,45 and 90 degrees allowed the robot to avoid walls very well and map the field.
  • Camera the camera allowed us to identify scoring walls and balls very reliably, and was calibrated specifically to the lighting in the final competition area, although it behaved very well in other lighting conditions. The camera's measurements were good enough that we could calculate the ball's positions with 1 or 2 inches of error at distances up to 16”.


The CAD & The Real Thing

CAD of Tallahassee.JPG Tallahassee.jpg

Software Design

Controllers

Quadrature encoders in the motors provide velocity and position feedback for the motion control system. An odometry module was written in order to parse the encoder ticks into angular velocities of the wheels, which is then integrated over time using a known model of the robot in order to provide accurate X, Y, and Theta with respect to the starting pose.

A generic PID Control class was written which could be given a desired value and PID constants, which was updated every timestep with feedback. The update function returns a command to use.

The motor controller module has three PID controllers within it: a velocity controller for the left wheel, a velocity controller for the right wheel, and a difference controller in order to maintain the desired difference in angular velocity of the wheels. The motor control module updates every main loop timestep and is fed the desired rotational and translational velocity of the robot (with respect to the world). The module then determines the appropriate angular velocity of each of the two wheels given the desired robot dynamics, and the three controllers are fed these values. The controllers return one command for each of the two wheels. Each command, in the range -255 to 255, is sent to the Arduino in two bytes over serial. The Arduino then sends the PWM signal corresponding to the command to the motor control board.

Vision

Mapping

The strategy used for mapping was a very simple one, based on the ideas taught in the 6.01 (Introduction to Electrical Engineering and Computer Science) class: represent the world as a 2D grid where each cell is a “bayesian wall”, that is, for each cell, there is a belief on whether it is a wall or not. We extended this to also include scoring walls and balls (however, due to time constraints, these capabilities were not used in the final competition).

That belief was updated based on sensor data: every time a distance sensor told us that a specific point was detected as being a wall, a straight line was created between the center of the robot and that point. All the grid cells in that line had their probability of being a wall lowered, and the end cell had it increased according to bayes rule and a rough model of the sensors (the probability that a wall is present, given that the sensor tells us there is a wall there was set to 99% and the probability that a wall is present given that the sensor tells there is no wall there was set to 1% - these probabilities were found in an empirical way).

Planning

Although it barely got used, we implemented ways to plan paths for the robot. One of the issues was that, even though they were heavily optimized for speed, it generally took a second or two to create a plan, which could cause issues sometime.

Planning happened in configuration space. Configuration space is the set of points that a point relative to the robot can exist in, without being in collision. For example, if we choose that point to be the center of the robot, and the robot was round with radius r (easiest example), then the configuration space would be the points at least r away from any wall.

To get maximum performance, the planning strategy used was greedy search/best first search (basically create a path by appending always choosing the closest point to your goal that you haven't chosen yet), followed by smoothing (if two points connect without collision, there is no point in having the points in-between belonging to the path – especially useful when planning with grid cells, since it eliminates issues with having points be too close together).

Configuration Space planning was used to avoid the robot getting stuck trying to reach unreachable balls, since it would classify them as such and the robot ignored them.


Getting it all together

So far, we described the basic capabilities of the robot, but they all got together at a higher-level by building state-machine controllers that join them together. Although originally a logic state description was supposed to exist that would allow the robot to make “smart” decisions, that was not implemented due to time constraints. Instead a simple state machine strategy was implemented that used three high-level controllers: wall following, picking up balls and scoring.

The state machine was as follows (picture):

Overall Performance

The team worked well together and we believe our performance was very good overall. We managed to design and build a robot, both mechanically and controller wise, that did exactly what we told it to do.

The final robot was stable mechanically (hard to topple-over and structurally sound), and had good controllers (capable of moving forward, rotating in place and moving to relative way-points thanks to the encoders on the motors, and avoided walls consistently thanks to the IR distance sensors).

The only part that required more work was the high-level strategy, which we didn't have enough time to develop and test (most/all of the issues found with our basic strategy could have been found with more testing in the playing field and we could have developed and tested a more sophisticated/better strategy given enough time).

We also developed a simulator that could have made it possible to test the high-level strategy if we had it earlier in the month (still, it wouldn't have replaced real-world testing).

Overall, we think we performed really well, given the time-constraints, and we are proud that we didn't just hack a robot together, but made a well-designed and mechanically sound one, with very good controllers (it also serves as a neat toy that catches our balls and returns them – kind of like bowling).

Conclusions

MASLAB was a fun and learning experience where we got the opportunity to work in a balanced team to get an interesting project done in an “impossible” (MIT-style) schedule.

The best moment in the whole month was when we decided to just work out the kinks and do our best to get a robot done for the final competition and managed to actually do it in a day.

We recommend other teams to try and stick to their schedules, and try to focus a lot on getting the design finished and prototyping a lot and quickly to allow the coders to test controllers and high-level functions. Even if the final robot is only made in the last week, the coders should be able to test on a real robot throughout the whole month. A really helpful tool also, is a simulator, if implemented early.

Overall, MASLAB was a really fun experience and we feel like we learned a lot and did something we can be proud of.

Personal tools