Deprecated: (6.186) preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /afs/athena.mit.edu/course/6/6.186/web_scripts/2011/w/includes/Sanitizer.php on line 1470
Team Nine/Final Paper - Maslab 2011

Team Nine/Final Paper

From Maslab 2011

< Team Nine
Revision as of 08:29, 2 February 2011 by Red Lion (Talk | contribs)
Jump to: navigation, search

Contents

Suggestions for Future Teams

1. Start as early as you can. Getting stuff done over the summer means you can relax more and not pull all nighters during IAP

2. Read past years wikis and the tutorials. They should point you in the right direction.

3. Get used to CAD for the meches and get used to Java and the Ubuntu command line for the programmers. It helps a lot to be able to build once from a CAD or to be able to minuplate you r computer without a GUI to save processing power (which will be quite limited)

4. Design a modular robot. If you have funky systems (like omniwheel drive) that needs work from programmers, build a chassis that can be taken off, so they can play with it to code while the meches continue working on the rest of the robot. We didn’t do this until it was too late and therefore got no (literally zero) testing before the final competition.

5. Lay out a schedule and STICK TO IT (we had one, but we kept pushing it back)

6. Don’t try to thread acrylic unless u never plan on removing the screw. Either the acrylic will crack or the threads will strip after two uses. Go for nuts and bolts, they spread out the weight better anyways

7. Have your nuts and bolts in easy to reach places. Our were hidden behind motors and rollers and it made deconstruction tough despite our modularity

8. Don’t epoxy until you are SURE your design is FINAL

9. Be careful of weight. If you use heavy materials like acrylic, sheet metal, and PVC, surprise, your robot will be heavy. Sacrificing smooth looks to cut weight is the smart move here.

10. Use a mouse for odometry, or better yet two, to have both an x, y, and theta coordinate.

11. The gyros are pretty bad, the encoders are worse, the mice work great, try to compensate. Another workaround for the gyros are compasses but we didn’t fool around with these.

12. Back up your code onto somewhere other than the repository. We lost the last week or so of our code on competition day when it was all mysteriously deleted. Not that it really mattered since we had so many other problems but be careful.

13. Finally, KEEP YOUR DESIGN SIMPLE, as a team with a majority meches, we got a little carried away on the design, and our brainstorming sessions led to a huge, heavy, super complicated robot. It was pretty cool, but the coders didn’t have enough time to test and the code was very complicated anyways.

Overall Design

Originally intending to build as simple a robot as possible, long nights of nothing but throwing ideas back and forth left us with quite the complicated design. From our chain linked, vertically mounted drive train, to our lidar system of mapping (aka two ir sensors mounted on servos), our design quickly became more of a task then we were probably able to handle. Still in the end we ended up with a pretty freaking cool robot.

Strategy Voltron is a robot that only goes for putting balls over the wall. Its basic principle is that it has a rubber band roller in the front to scoop up balls, and a large roller in the back to lift balls up to the second level. in hindsight one roller couldve performed both tasks, but hey hindsight is 20/20. When the balls get up to the second level they are held in a collection bay until the robot drives up to the yellow wall, then the gate lowers and the balls are released. The gate is long (6") to allow a factor of safety in aligning with the wall. Other features are two ir sensors mounted on servos that can map out 180 degrees around the robot without the robot itself having to turn. It is basically a poor man's LIDAR. We also have 4 omni wheels that allow our robot to move and turn in any direction, allowing us both to strafe and to rotate. Finally, we have a gyro to align the data from the LIDAR, two bump sensors to determine when we have hit the yellow wall, and an optical mouse for odometry (we originally wanted two but we didnt have time to install it, nevermind code for it)

Materials

Our robot was constructed entirely of acrylic and sheet metal, along with any other parts we had ordered, including sprockets, chains, steel axles, and angle stock. We chose acrylic because it looks hella cool and we thought Voltron deserved to look good. We wanted to be able to see the ball over its entire journey through the bowels of our robot, so acrylic made sense. Its also very easy to lasercut and drill through, the only problem is it was kind of heavy, pretty brittle, and it was sparse. We got lucky in that we found extra acrylic lying about, but we couldnt always count on being able to replace broken acrylic pieces. With the extreme weight of our robot from the acrylic and sheet metal, we decided that the gears running the wheels and rollers should metal instead of plastic so they wouldn't strip. This turned out to be quite unnecessary as I dont believe any other team had stripping problems, and our robot became that much heavier (and more expensive). As you can imagine we had a very heavy robot.

Sensors

Outside of the typical uorcboard, camera, ir senors, bump sensors, servos, and 2 or 3 motors, our design required, an optical mouse for odometry, 3 additional motors, and with that an arduino. Each of these components had to be mounted, of course, and we did so by creating seperate sheet metal cases for the arduino, eepc, and orcboard, and mounting the servos and ir sensors, as well as the camera, on a senors board located underneath the dock where we collected balls. The 4 drive motors were all located above there respective omni wheel, and connected via chains.

Vision

In the end, we opted for a very simple approach with our vision code; frames were taken as quickly as possible, and each pixel was scanned and sorted by color. Neighboring pixels of like cluster were then sorted into blobs, and blobs were treated as viable objects: red and green ones were balls, blue ones were the lines atop the walls, and yellow were goals and scoring walls. This simple approach was relatively fast and could reliably pick up walls and balls; we accelerated it further by down-sampling the image (that is, checking only every other pixel, or every fourth). The biggest issue we had was localization using the camera; the accuracy we achieved using things like blob size and offset within the image was not high enough to be useful, varying by as much as a meter while the robot sat still. Our final vision code was dramatically simpler than our original intention. Although we initially implemented several advanced features, including Hough transforms and confidence calculations, they were all ultimately removed in the interests of speed and because they didn't offer any particular advantage in the context of the contest. Red or green meant ball, yellow meant goal, and blue meant the top of a wall – anything more complex was largely irrelevant. That was one of the major lessons learned during MASLAB: however cool or interesting a feature may be, if it doesn't contribute to performing in the contest, it probably isn't a good idea. There's nothing wrong with trying exciting new things, but the time constraints mean that you'll have to pick and choose which exciting things you do – and generally, the ones you want are the ones that will help you win.

Omniwheel Drive

The same lesson applies to our drive train. We chose to build a four-wheel omni-wheel system for enhanced mobility; four wheels were chosen because of the natural symmetry of the robot, and because of size constraints, the motors were mounted above the wheels and connected by chains. Although we were successful in building this complex drive train, it was plagued with issues – the weight of the robot meant the wheels needed to be mounted on steel shafts to avoid excessive flexing, the low wheel-base meant the robot occasionally dragged on the floor, and the number of motors meant we could not use the orc board to control the drive system. As it turns out, the omni-wheel system didn't even offer us much of an advantage; because of the nature of the contest, robots were almost forced to use 'turn and go' navigation, rather than executing the complex paths the omni-wheels would allow. Had we used a conventional two-motor drive train, we could have avoided a lot of work with minimal impact on practical mobility, and used the extra time to implement things that could have greatly improved our performance in the contest.

Modularity

The final point I would like to make about our robot is its modularity. I would definitely recommend this to future maslab teams when designing. Originally our robot wasnt modular at all. Our first build took us over an hour to finish (Check out a time lapse of our original build here: http://www.youtube.com/watch?v=8_epFGdMhL8). Eventually we cut our robot down and added more brackets and supports to make a modular design. Our robot then consisted of three main components that could be separated with ease to, for quick access fixes and changes. We cut our construction time by over 50%. The three components were our left and right wings, and then our center console. The left and right wings were composed of the front and real wheel assemblies, each of which consisted of a motor mount, a wheel mount, and a chain and sprocket system. These could be bolted onto the sides of the main compartment, which was 7' wide and flat on both sides. This helped us dramatically when working on our robot, and it ended up being one of our proud points in the design.

However, despite our modularity, it ended up being too little too late. An ideal module system would be for the wheels to be on one module, the sensors on another, and the ball collecting aparatus on a third. This way the coders couldve been testing omniwheel code and sensors code while we finished the build. As it turns out, the coders didnt get the fully funtioning robot until about 6 days before the final competition. This certainly was cutting it close. But then the problems with weight and the robot dragging on the floor, and the failure to identify these problems, meant that the coders never finished their code, and our robot ended up driving straight and blind at the final competition. Moral of the story: make your designs modular so every one can be working at once.

Final Outcome

Unfortunately our robot did not seem to come together like we had intended. On the day of the final competition we simply did not have a robot ready for the task at hand. For the preliminary round, we lost in both 3 minute sub rounds, scoring zero points. Come the second round we stepped our game up a bit collecting one ball and displacing another. after dropping the one ball we collected, however, we still ended up with zero points. We ultimately came in second to last place. Despite our limited success both my team and I can certainly agree that experience was one filled unmatched learning opportunities. It is an entirely hands on project that will force those who are not experienced in the field to learn new skills they will undoubtedly be able to apply in the future. I recommend this to anyone interested. Voltron force, out!

Photo Gallery

File:Robot1.jpg
CAD View 1
File:Robot2.jpg
CAD View 2
File:Robot3.jpg
CAD View 3
Robot View 1
Robot View 2
Robot View 3
Lasercutting dxf
Mid construction
Our workspace
Maiden voyage
Swag Master Flex working hard
Personal tools