Quote:
Originally Posted by GeDarkanator
we are 20-25 students in the team. we some engineering support but not alot of it.
|
With a new team and not a lot of engineering support you want to make sure you do not over commit by attempting too much. For example, it sounds like you are building a robot that climbs (possibly above the first level) shoots, and picks up Frisbees both from the feeding stations and the floor. That is a lot to try for given your experience and resources. I am not saying do not try for that if your team wants to. Just have some fall back plans.
Perhaps work on only accepting disks from the feeding station for now, and consider picking disks up from the floor later if you have more time and resources. The most common mistake teams make is not being realistic about what can be accomplished during the two week build build period.
You heard me correctly, the build time for a robot ideally (in my opinion) is only two weeks. One week gets consumed in strategy, design, and possibly acquiring any specialized components. Then you need to finish the building in time to leave one or two weeks for integration, programming, debug, possible retrofits to correct issues, and driver practice. If you build a robot that does less, but is completed early enough to allow extensive testing, debug and practice, you will be much better off that if you build one that does everything you wanted, but is finished on the last day of build season and not fully debugged.