[Astronouth7303]

In addition to debuting the scripting system I wrote in the pre-season 2006 (that we ended up not needing -- it was a very strange robot), I tried a few structural things.

The scripting is based on preprocessing direct calls to functions, instead of Kevin Watson's structure-based navigation code. (The preprocessing is so that the script will abort when autonomous ends.) It follows the idea of a lot of little loops: every command calls HEARTBEAT at least once, and that handles getdata() and putdata() calls. This all makes C-like syntax:

SCRIPT drive_half_field()
{
    CMD_UNFURL(NO_WAIT);
    CMD_DRIVE(FEET(20));
    CMD_TURN(DEGREES(90), RIGHT);
    CMD_WAIT(SECONDS(2));
    CMD_HOME_IN(); // Drives towards the light
    CMD_DROP(); // Drop that keeper!
    CMD_DRIVE(INCHES(-18));
    CMD_TURN(DEGREES(90), LEFT);
    CMD_DRIVE(FEET(20)); // And maybe crash into someone!
}

You can also stick in loops, ifs, or any other constructs, calls, or whatever you want. Just call HEARTBEAT if you go too long.
One of the big ones this year was that every mechanism followed a standard interface. Every mechanism had the following macros or functions:

• NAME_Init() -- Initialize state
• NAME_UserMode() -- Perform operator mode controlls
• NAME_Sensor() -- Take sensor readings at the begining of the slow loop (autonomous or user mode)
• NAME_Process() -- Handle control loops at the end of the slow loop
• NAME_IsDone() -- For mechanisms that moved to a position, had it reached its position?
• NAME_*(...) -- Any control functions (eg, Arm_GoTo(ANALOG val), Drive_1stick(UCHAR drive, UCHAR turn), etc)

This was facilitated by wrappers around getdata() and putdata() which handled this. Note that these functions are used in both autonomous and operator mode.

I also had my usually tools, namely pinouts.h (a configuration file of all the hardware I/O aliases and tweaking constants), Eclipse, and old code.

Also, I'm the operator this year, so I can make it as complex as I want. (Because I know how it all goes!) Ok, not really. There is a backup driver that I have to keep up-to-date.

Amongst the things I may do between now and our competitions:

• Write a generic python script to generate lookup tables
• Write another LCARS Dashboard for this year's robot (likely in python, so that I can develop on my Linux desktop)
• Adding a real-time clock using one of the timers

Originally Posted by benhulett

Designed a "level code" to make the arm operator's job 10x easier
Ex: you push this button, the arm moves to level 2 and sets the motor to neutral (until you push another button)

We have that, too. We just used a pot, though.

Originally Posted by tdlrali

We wrote some code that eliminates the need for a programmer...
More on this later

Isn't that ironic? Writing code to keep you from writing code?