Bad luck, or poor execution?

[VKP]

The most effective way to improve your robot (as our team has found) is to build a second robot to practice with between ship day and the competition. Our team worked out a lot of kinks and other problems with our practice robot which we otherwise would have had to deal with at the competition.

I strongly suggest you guys do this next year. It helped us tremendously (we are now using our practice robot to practice with a new roller claw we build for the championships!)

[nitneylion452]

We actually did build a practice robot; however, it was not ready until Monday, i.e. two days before the competition. This was due in part to all of the new sensors we were using. Plus, there were some minor differences between our competition bot and practice bot.

[Chexposito]

the sooner you get a rolling chassis of the type of drivetrain you want to use, the more time the programmers have to work on code. try to make sure you get your final robot done as soon as possible, then immediately start building your second as close as possible. that way on ship day, they can transfer to the practice easily and keep working on code. usually they are running the robot to it's limits, so problems with the design or manufacture are found in your shop instead of at competition. most teams experienced teams use the 30 lb. withholding allowance to their benefit, so whatever you fix you can build the fix and bring it with you. safety inspection is important to make sure your ship robot will pass. reading the robot section of the game manual can help with most of these problems. as for not reaching the top peg, testing on with game field elements that are somewhat accurate or really close is key.

so pretty much test, test, test and when you're done with that test some more.

[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!