FIRST Lego Team 71229

How to Program

You can program the robot either through a web-based or downloaded application. The common method is using "word blocks" (similar to Scratch), but Python is possible if you're willing to try it!

Feel free to try coding at home! There are three ways to bring your code in to try on the team robot:

  1. Take a screen shot of your code, and we can recreate it.
  2. Bring your computer and we'll connect it directly to the robot.
  3. Download the code to your computer and email the file to the coach.

Note: This last method will be preferred when we start assembling our competition code.

Robotics Coding is Sense - Think - Act

1. Begin with "Pseudocode"

Before assembling any mechanisms or writing any code, begin by writing out in plain language, step by step, how the robot will solve the given problem.

What sensors will it use? How will it react to those sensors? What decisions will be made? What actions will be taken based on those sensors and decisions?

2. Make an initialization routine first

Before coding any actions, begin with a startup code which resets sensors, sets motor ports, initializes variables, and otherwise ensures the robot will always begin with the same starting "state."

Use a "template program" when building and testing other mission codes.

3. Make one change at a time. TEST EACH CHANGE

Do not attempt to code everything, or even half of everything, all in one go. Build step-by-step, checking each step for success.

Do the correct wheels spin? Do they spin in the right direction? Do they spin for the right distance? Does the first turn work?

4. Test your code in pieces

Build and test movement code separate from mission mechanism. Build and test mission mechanism separate from return. Build and test return separate from the other two steps.

Then assemble those steps one at a time.

5. Make your code MODULAR

When possible, use MyBlocks to avoid repeat code, enable unit testing, and build more complex actions. This way you only have to make a change in one piece of code to fix a problem, and you can build complex actions out of well-tested subroutines.

Example MyBlocks could include:

6. Consider "Closed-Loop" Feedback Control

It is one thing to tell the robot to move in a straight line. It is another to check while it is moving that it is moving straight. When possible, incorporate some means of continually checking and adjusting commands to account for bumps and slips.

7. Test for Robustness

It's not sufficient that your robot can accomplish the task at least once, i.e. it is successful one out of ten tests. You must design so that, as best you can, it cannot fail, i.e. it succeeds nine out of ten tests. If bumps, slips, or alignment errors result in failure, figure out a way, either in code or mechanically, to make success more likely.

Accurate movement depends on alignment and feedback. Don't rely on luck! Use jigs and gyros!

8. Assemble different mission codes into final code.

Be careful! A lot of confounding errors can appear when several large code sequences are combined. Make sure variables aren't interfering or not being reset across routines.

Check, check, check!

Like above, assemble and test a piece at a time. As much as possible, design code so that different missions can be interchanged without breaking the code.

9. Make a checklist for running the missions

Have printed/handwritten notes of which program to run, what mechanisms to use, and any inputs that need to be provided. Don't rely on your memory! It is liable to drop something in the excitement.

Keep notes while you work. It will save you later!

10. Use a naming convention. Make BACKUPS!

E.g. program number, version, date

Use comments in code: mission numbers, version, recent changes.

Don't copy over existing working code.

Save backups in multiple locations. Always have a way to REVERT if something breaks!