Team Nine/Final Paper

Revision as of 15:58, 2 February 2015 (view source) Team9 15 (Talk | contribs) (→Our Philosophy) ← Older edit		Revision as of 16:10, 2 February 2015 (view source) Team9 15 (Talk | contribs) (→Reflections and Tips) Newer edit →
Line 43:		Line 43:
	==Reflections and Tips==		==Reflections and Tips==
	===What Went Well===		===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===		===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===		===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==		==Conclusion==

---

Revision as of 16:10, 2 February 2015

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 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

So we used opencv. Protip don't use it

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