Quote:
Originally Posted by DonRotolo
Somewhat related comments:
I think deconstructing your last bot is a great idea, but add the goal of reassembling it again. It will make a dandy test mule for ideas.
As for mentor overload in the design arena: Instead, teach the kids how to follow a prioritized and iterative design process. By that I mean the should...
.snip.
(Programmers start in Week 2 BTW because the mechanisms are defined already).
|
Eep! Your programmers should be involved from the very beginning! A robot is a systems challenge, you need to make sure the mechanical people know where to put those pots and encoders, and the software people need to know what kind of response rate they'll be getting from the mechanism and what kind of automated functions they'll be expected to generate. In particular, most teams do not have programming geniuses that can make complicated mechanisms easy to control so its vital that subteams work together to generate a design that can be fully fleshed out mechanically and robustly coded. Many a decent arm has been rendered ineffective by a jumpy non-linear response to driver inputs, and I've lost count of the number of Mecanum drives that end of spinning in circles in a corner of the field.