Bad luck, or poor execution?

[DonRotolo]

A team needs to consider what they are really capable of. If your second robot wasn't ready until several weeks after the first one was built, perhaps you "bit off more than you could chew". As a suggestion, consider a simpler robot next year, and focus on robust and 'done early'. That will set you up for future years of excellence.

[BigJ]

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:

1. Mecanum drive working correctly
2. Lift operable using manual up/down controls
3. Lift maximum limit switch operational
4. Encoder on lift drum shaft, used for preset positions
5. 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)
6. 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.

[nitneylion452]

Originally Posted by DonRotolo

A team needs to consider what they are really capable of. If your second robot wasn't ready until several weeks after the first one was built, perhaps you "bit off more than you could chew". As a suggestion, consider a simpler robot next year, and focus on robust and 'done early'. That will set you up for future years of excellence.

The physical building of the practice robot was actually finished maybe 3 or 4 days after ship. We had wanted to add "just a few more sensors" to the robot. These included IR distance sensors and encoders. Our programmers worked frantically to get the code working, but so many things kept not working correctly that the process was dragged out over the course of a few weeks.

The entire process was made more difficult because our practice area was not in the same building as our workshop. We are located in the basement of a building behind our school and our practice area was on the school gym stage. Most of the programmers' tests needed the full size replica to be accurate, so in order for us to test the code, we had to bring the robot, tools, and various other items over to the practice area, which was about a half hour process.

I don't want to sound like I'm making excuses, I just want to provide some insight about our situation.

Thanks again for all of the feedback!