From a control systems perspective, I'd suggest an iterative and segmented approach. Make sure base functionality is working, then integrate sensors as you go. We try to provide a way to "cut out" the sensor code, so that if it still isn't working, or started not working, and we need to queue for a match, it takes little more than a few seconds and a redeploy to have the robot is a correctly working state.
Here's an example:
1675 has 2 major control elements this year: Mecanum drive and our lift system.
Our rough development schedule through the year was as follows:
- Mecanum drive working correctly
- Lift operable using manual up/down controls
- Lift maximum limit switch operational
- Encoder on lift drum shaft, used for preset positions
- Automated scoring procedure using lift and claw with encoder once tube is snagged on peg (this is where we are now, and will be implemented on Wednesday at CMP)
- Drive encoders for more precise control (doubt we will have time enough to put them on and test)
(There was minibot stuff too, but just flipping a few servos.)
We use C++, so each of the above past number 3 have alternate functions that can be used to revert to proven, mostly reliable alternatives. Class constructors are defined for the components of our robot to be used with or without sensors, and a simple change to a line at the top of our main robot file switches what sensor groups will and will not be used.