[ay2b]

As almost everyone has said, some sort of version control system is a must.

I'd personally recommend against having competing teams, unless you did that all pre-season. During the season, I would try to avoid doubling the work you do, knowing half of it will be discarded. As an experienced C/C++ programmer, I found LabVIEW (at least the basics of it) fairly easy to pick up, but I'd recommend going with what you know. Either learn LabVIEW before the season starts, or use C/C++.

My recommendation for how to organize/divide the students is to have 4 or 5 teams. Each team is responsible for a separate component of the software.

a) robot interface -- using an object-oriented approach (which doesn't necessarily imply an OO language), this team provides an interface "to the robot". Present functions such as "drive at this speed", "move arm to this position", etc. This team would be responsible for integrating sensors, implementing PID control loops, etc.

b) autonomous operation -- using the interface provided by team (a), develop the autonomous operation.

c) teleop code -- using the interface provided by team (a), develop the teleop code. This team would probably also help to design the operator interface. Should we move the arm with a joystick, or have buttons to move to set positions? Should the arm joystick control the arm position or the arm motor speed? Do we use 1-joystick drive, or 2-joystick drive? etc.

d) dashboard code -- this could be the people who really want to use LabVIEW or C/C++, whichever you chose not to use on the robot.

You might split team (a) into two teams, one that does the drive (and encoders, gyro, DAA, etc for positioning the robot on the field) and one that does the manipulator (and associated sensors).