Organizing many programmers

[Russ Beavis]

Depending on the cost of a spare cRIO (hopefully we'll get that info soon), you might want to consider dueling software teams - one with C/C++ and one with LabVIEW.

Another option to consider is a LabVIEW-based Dashboard app and C/C++ robot programming. There's definitely room for both.

You may even be able to use C code within LabVIEW and have high-level "systems engineers" coding in LabVIEW and "low-level software engineers" coding in C. However, I'm not sure whether the FRC version of LabVIEW will provide Code Interface Nodes or similar for integration with C code.

Sounds like you've got a big team! Keeping everyone "happy" might be a bigger challenge than the actual game. Good Luck and Have Fun!

Russ

[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).

[EHaskins]

The only thing I can add is that you should use some type of version control, even if you've only got one programmer. I use SVN. Its is a fantastic tool, especially when combined with TortoiseSvn.

[AustinSchuh]

If you don't mind your code being publicly viewable, you can host it on Google Code. Google Code provides a repository for your code (subversion by default, I think), and places for a wiki.

http://code.google.com/hosting/

FYI, I don't remember what license the code we will be using will be released under and whether we are allowed to make it publicly available...

[Andrew Schreiber]

Since version control has been mentioned I will mention code standards. Possibly not as big a deal with Labview but still worth considering.

[Joe Hershberger]

Originally Posted by Russ Beavis

Depending on the cost of a spare cRIO (hopefully we'll get that info soon), you might want to consider dueling software teams - one with C/C++ and one with LabVIEW.

Another option to consider is a LabVIEW-based Dashboard app and C/C++ robot programming. There's definitely room for both.

You may even be able to use C code within LabVIEW and have high-level "systems engineers" coding in LabVIEW and "low-level software engineers" coding in C. However, I'm not sure whether the FRC version of LabVIEW will provide Code Interface Nodes or similar for integration with C code.

LabVIEW Full for FRC supports call library nodes. You can build a .out file from your C/C++ code using the WindRiver tools and then call that code from LabVIEW using the Call Library Node. The entry points that you want to call from LabVIEW need to be C functions (and C calling convention). Code Interface Nodes are not supported on the cRIO... they are deprecated even on Windows favoring Call Library Nodes.

[Tom Bottiglieri]

A few things:

Windriver Workbench for FRC has an SVN client feature. I think we will be using that over TortoiseSVN or a similar tool.

We plan to have parallel LabView and C++ development going on. The LabView core will be our less experienced students, and will mostly be working on a dashboard and test drivers for specific function tests. (Camera/encoders/PID gains/etc).

I've found that wiki's are a good organization tool as well. They are available for free all over the web, or you can install your own if you have a web server.