Quote:
Originally Posted by Bongle
The programming team only gets robot access when all those things are done, which is never. You need substantial alone time with the robot during the build period in order to develop and test autonomous mode, which requires a fast hardware team.
|
As an embedded computing veteran, I can assure you that what you've described happens a LOT in the real world too, and it's often the downfall of any new system. Software is always placed at the end if the "critical path" for robot designs, mainly because programmers are not pro-active enough during the initial design stages. They often let themselves be back-burnered because they like working in isolation.
Unfortunately, these days you can't say "hey, we really don't need autonomous mode" because it's going to be more and more critical to future "real-world" robots.
So it's important that guys like me, teach young programmers the importance of being an active part of the design process, establishing software requirements early, and learning how to be an asset during the build so they get the required "face time" with the robot.
I've learned that if the programmers allows themselves to be put off till the end of the build, the overall team will suffer (and I'm not just talking FRC here). It happens all the time in industry.
So, I beleive that Autonomous doesn't need to be longer, it just needs to be more integral with the game (like in Aim High). The whole team needs to see the benefit to a good auto mode so that the programmers get to be involved in the design process early. It shouldn't be so easy for the mechanical guys to say "we don't need auto, we can push any robot".
If each aspect is seen as important (mech, elec, software) the design groups will learn better habits for the real world.
Phil.