Quote:
|
I will say anyone considering getting together with a group to do a robot in 72 hours should think twice about why they are doing it. Just as FIRST has a scalibility issue it is tackling with districts, what would happen if in 5 years we had 50 72 hour robots taking place? Could be a crazy number but I'm sure it would be very easy to find 50 groups who'd be willing to do it. Do you think that would have an impact the community?
|
Here's how I'd like to see this 72 hour robot process improved in the future:
1) Having more than a couple of these 72 hour projects going has the effect of exploring the solution space more thoroughly than I'd like. Last year with one robot in three days we got to see one good way to build a minimally competitive robot. That was good. Six robots this year explored the options so thoroughly that there is less room to innovate. Can you still do things better? Sure. But I think we've now seen the broad outline of what 90% of the robots at the competitions will look like. I'd like to see the number of teams doing 72 hours robots reduced next year.
2) Don't release CAD files or detailed walkthroughs until after the season is over, if ever. Reasons have been discussed previously in this thread.
3) I'd encourage the 72 hours teams to intentionally keep it simple. Many of these teams are run by competitive, brilliant, type-A personalities who naturally want to do the best they can. What they can do in 72 hours is better than many teams can hope to accomplish in six weeks. We run the risk of demotivating kids when their accomplishment over the build season isn't competitive with what the pros could do in three days.
4) Show robots failing in release videos. Don't just edit it to show the times when the robot worked great but show it not working so students can see the designers are human. It will make them feel better when their robot fails.