Team Nine/Final Paper

Contents 1 Introduction 1.1 The Team 1.2 Our Philosophy 2 Strategy Rationale 2.1 Initial Thoughts 2.2 Key Design Considerations 2.3 Goal 3 Key Hardware 3.1 Claw 3.2 Turntable Sorter 3.3 4-Bar Linkage Arm 3.4 Stack Canister 4 Software Development 4.1 Overview 4.2 Computer Vision 4.3 Wall Follower 4.4 Color Sensor 4.5 Integration 5 Competition Performance 5.1 Results 5.2 What Happened 5.3 During The Rounds 6 Reflections and Tips 6.1 What Went Well 6.2 What Didn't 6.3 Future Improvements 7 Conclusion

Introduction

Team 9 (i.e. Team Underpowered -- U.P.) consists of three practical and mechanically-savvy AeroAstro students and two C.S. rockstars. We formed because of strong UROP, fraternity, and course major ties, but we stayed together and finished strong because of our mutual respect and dedication to our beloved robot.

The Team

With Kurtzy, Tratt, and E.Jordan spearheading the design of the mechanical monster and Sandy + Lerner = let there be code, our team subdivides based on expertise to great effect. 3D printing blackbelt Kurtzy, also the woodshop master at Simmons, has the most experience with fabrication and assembly of badass projects. Resident chess expert Tratt helps with the strategic sacrifices. E.Jordan definitely carries the team when it comes to being lolzy. Sandy Cheeks cannot be bothered to debug since his code is so darn fly. Why is he called Lerner? Since he already learned everything he needs to know. In kindergarten.

Our Philosophy

Win.

EDIT: good luck with that, noobs. Try new philosophy: move.

Strategy Rationale

Imagine you have two stacks, one red and one green, with n blocks each. If you pick up a stack of 3 blocks, 2 red and 1 green, is it more beneficial to sort them and increased n^2 or to place them on the central table as a stack of 3? These are the questions you must ask.

Initial Thoughts

Given that the table option increased the score multiplier, unless n is less than or equal to 3, then it is beneficial to place the stack on the table. Our initial thoughts centered on maximizing points, but with changes to the game rules, our final strategy is to score in all possible ways, using two tall canisters to sort and stack the blocks while placing a stack on the center table to obtain the 3x multiplier if possible.

Key Design Considerations

Stacking the blocks flush with the ground at all times ensures point scoring even in the event of catastrophic robot failure. Tolerances on key hardware such as stack canisters, claw, and dispenser mechanism are engineered such that passive geometries will enable 100% success rates in block flow without jamming. Software is created as simply as possible to increase robustness; simple wall following and Boolean block finding methods enable easy block collection with minimal efficiency sacrifices.

Goal

Our goal is to collect all block stacks, place one with our color at the top on a middle table, and deposit one large stack in the purple area to score with the opponent's color while scoring with our color at our end position on the field. We should in theory get (6^2 + 6^2 + 3^2 ) * 3 = 243 points with 7 green and 8 red starting blocks on the field.

Key Hardware

Measure twice, cut once.

Claw

Our robot would be nothing if it could not pick up blocks. Through four iterations of claw design, we discovered that robustness is necessary when teammates step on components. The final version of the claw includes an approximately 3" diameter cylindrical grip with mdf paneling to allow for slippage when depositing blocks onto the turntable sorter. The diameter enables gripping of blocks in any orientation with respect to the xy-plane, and the geared, servo-actuated opening and closing enables a large enough sweep area for ease of control when aligning and picking up block stacks.

Turntable Sorter

The turntable slide is angled both backward and sideways to let science happen (gravity). Blocks are deposited by the claw into the channel where they rest until color is detected by a homemade LED-photocell sensor. Proper alignment for the turntable is chosen based on the sensed color; after the turntable is moved to the correct position by the 131:1 Pololu motor, a servo-actuated puncher pushes the block out of the opening and the block falls nicely into our stack. Even if it didn't fall nicely, the geometry of the components would ensure proper stacking. The puncher is designed to constrain other blocks from falling while the known-color block is being sorted.

4-Bar Linkage Arm

The claw is lifted to the sorter by a 2:1 gearing of a 131:1 Pololu. Using Solidworks to figure out the exact hole placement (intersection of midpoint altitudes of final, mid, and initial positioning of claw), arms and holes are created to transfer blocks from their stacked configuration on the ground to their deposition onto the slide. This geometrically awesome little piece of engineering enables us to have the coolest lifting mechanism of any team, one which is far less prone to jamming than conveyor belt-type lifters. The arm does not change angle rapidly, so a 4-inch clearance is possible when attempting to stack blocks on the communal central tables.

Stack Canister

The diagonal of the 2x2x2 cube should be able to just fit inside a proper stacking container to ensure jamming-free fall into stacked orientation. Our canisters drag on the ground to minimize mechanical interactions which introduce unnecessary complexity into the system. Since they already drag on the ground, a door must simply be opened and the robot can drive away to leave a canister and accompanying block stack behind in any desired location.

Software Development

Overview

We chose to write the software in C++, as we felt it would allow us to implement faster as opposed to having to go through JNI if we chose to use Java. While this allowed us to save time by not having to configure JNI, we also ended up not being as efficient since we did not have as much experience in C++ as we did in Java. Our software consisted of multiple modules, developed independently, brought together at the end.

Computer Vision

We used OpenCV to capture and manipulate our images. At first, we used OpenCV algorithms to detect colors, but we soon realized that this would not be fast enough for our underpowered Edison. Instead, we ended up writing our own algorithms for detecting blocks and walls. The main component of our color detection module was a flood filling algorithm, which would find the largest body of a certain color on the screen and collect information about it, such as frame position, dimensions, and size. With this information, we were able to efficiently and reliably calculate the position of objects relative to the robot. We aimed for real time image analysis, so we could rely less on calibrating our constants and more on the fact that a feedback loop could allow the robot to converge on an object.

Wall Follower

For our wall following algorithm, we used three short range analog IR sensors along one side of the robot. We ended up going with a PID controller for wall following, ala 6.01. Along with the PID controller, we also checked for many edge cases in which the robot could get stuck and made the robot take appropriate behavior.

Color Sensor

To detect the colors of blocks once they were collected, we used a red LED and a photocell. We shined the LED on a block and used the photocell to read how much light was reflected. This method worked quite well. Once a color was detected, a rotating platform would move the blocks over the appropriate stacking cube, and a servo would push them in.

Integration

We developed each of these modules independently, so splitting up work was straightforward. Once these modules were developed, it was trivial to combine them into a state machine to be used as our final software. We just needed more time to tune our constants.

Competition Performance

Results

Fourth Place Most Likely To Become Staff Award Only one win in first round, and that was a tiebreak on weight since neither robot scored. Sad Face.

What Happened

The night before the competition demonstrated how woefully inadequate our software-hardware team relations were. The robot broke in multiple places, the third claw design was deemed inadequate, and much rebuilding ensued up to and during the actual competition. Duct tape was used in obscene quantities and our code could not be properly tuned since there was no finished robot!

During The Rounds

Our bot got stuck numerous times, since the 4-bar linkage arm had too much reach outside the robot's body. The webcam saw the blocks and kept lowering the arm, but it did not work since the arm just went over the blocks. Power levels were insufficient, so we became indefinitely stuck on minor turns. Essentially, we were one of many MASLAB teams that learns the hard way that moving is non-trivial.

Reflections and Tips

What Went Well

• Team worked well together and had a blast, working with many many hours in the lab to earn the Most Likely To Become Staff Award
• Certain components were individually very strong and reliable, such as the turntable, the vision code, and the stack cannisters
• Learned a lot about project management, design, and implementation

What Didn't

• Built multiple robots...huge waste of resources and time
• Integration of components (mechanical things, sensors, and software) was never finished. Parts were not designed with goals in mind. We did not have a finalized design before we started building. That is when tape becomes involved. Adhesives are a no-no...at least, try to avoid through thorough design in future.
• Certain team members may become demanding and/or stubborn. This can be burdensome to the team. Always remember to respect others and their ideas. It can be so crazy, it just might work (to quote The Master of Disguise.
• Timeline: hardware should be done before the competition. Duh. Give time to tune the software. If we had one more day, we could have made everything work through tuning. But also, we didn't plan for the nuanced control that our robot required to pick up blocks with its high-precision arm. THIS IS NOT A HIGH-PRECISION COMPETITION and should be treated as such. Design something that will work regardless of drive geometry, etc. For instance, use the darn conveyor belts.

Future Improvements

• Build the robot with electronics and sensors in mind. Never consider it easy or something to put off until the hardware is built. Design, design, design.
• Meet every day as a team, break down the robot into tasks and modules, list goals and subgoals for each task and how each piece plugs into the whole thing, keep this list updated and available
• Team conflict resolution and decision-making processes should be better defined
• Talk to the instructors early on, get their feedback on ideas and really listen to them. They know what they are talking about.
• Keep trying new things. We went for it, and learned a lot in the process. Probably more than if we had won because it drove home how imperfect things are until they really work.

Conclusion

Thank you to the Sponsors and the instructors of MASLAB, it was truly an amazing experience. Thank you Charles Guan for all the tips and tricks and great lab equipment and upkeep, and especially thank you to Evan Wilson, who dedicated extraordinary amounts of time to always be with us in the lab, even at 4am. We would certainly recommend MASLAB to all interested parties. You should probably cut all ties to the outside world and not do anything else for IAP though. Trust us, it is worth it.