Checkpoints

From Maslab 2007

Jump to: navigation, search

Checkpoints will involve a ten minute meeting with 2–3 staff members. The staff members will ask about your robot’s progress and your plans, and suggest changes.

Contents

Checkpoint One

Robot proposal

For this checkpoint, you should prepare a ½–1 page written description of your robot’s features, plus sketches of your robot’s physical design.

You should also make a schedule that includes when you will be working on what, and when you expect features to be done (also, think about what you will do if your features are not done on time). This proposal is what your meeting with staff members will be about.

Robot progress

By this checkpoint, your robot should be able to turn itself until it sees a red ball, drive up to it, stop, and publish something to the BotClient. If your robot cannot do this, your team is behind. A staff member will be checking that your robot can do this.

Checkpoint Two

For this checkpoint, your team should be making progress towards having a robot that is not the pegbot, and progress towards scoring a point. The staff will want to know where are you in relation to your original schedule and design.

Checkpoint Three

Your robot should be able to wander, find balls, and score with the its primary scoring mechanism.

Checkpoint Four

This checkpoint is the final assessment before the final contest. Your robot should be mostly done, except for minor tweaking.

After this point (and if at all possible, for some time before it), you should probably be spending most of your time testing your robot in full multi-minute runs of your exploration code on the largest playing area you can find, and finding bugs where your robot gets stuck or otherwise fails to recover from an error condition. Every year, we see several teams who put a lot of effort into robots that get stuck early in the contest because of some stupid bug that they didn't test enough to catch. Don't let this happen to your team.

Personal tools