Organizing many programmers

[Goldfire]

This is my first year involved with FIRST (joining other mentors with more experience) as the programming mentor. We have team of 30-40 students, of which about 15 are interested in programming. They range in programming experience/knowledge from nothing at all to halfway through AP Computer Science. My personal experience is quite deep in C/C++ and non-existent in LabVIEW. I have no experience with robots of any kind.

I'm looking for suggestions of how to organize my students. Would it make sense to split into some who will specialize in LabVIEW and some who will specialize in C++? Should they all learn both? Is this an unmanageable size and should I work to encourage some to find other pursuits?

Somewhat separately, is anyone aware of good websites teaching programming basics for those totally new to the field? We don't have adequate time to warm the complete newbies up, but I'm hoping they can learn on their own.

Thanks!

[Dave Flowerday]

Originally Posted by Goldfire

I'm looking for suggestions of how to organize my students. Would it make sense to split into some who will specialize in LabVIEW and some who will specialize in C++? Should they all learn both? Is this an unmanageable size and should I work to encourage some to find other pursuits?

I personally think you'd be best sticking with one language only (for your own sanity). Since you already know C++, that seems like the obvious choice. It's hard enough ramping up new students when you know the language.

We have between 10-15 programming students on our team the last few years and it has worked out for us. We split them up into teams to focus on different tasks (one focuses on drive code, another on arm manipulation code, etc). If necessary we break the group into 2 and have them come on alternate meeting days.

With a team that size, a good version control system is a must. We use Subversion and are very happy with it. Subversion (and several others) can be installed locally on a laptop so you don't have to worry about setting up a server. Obviously merging C++ code with something like Subversion is pretty easy - I'm not sure how that works (if it does at all) when you get into a graphical application development environment like Labview.

[Joe Ross]

We haven't had quite that many programmers, but once our number got above 3, we started using revision control (CVS). It made keeping track of everything much easier. We used TortoiseCVS as a gui for it, which made it easy for people who were new to CVS to start using it quickly. Subversion is just as good, or better.

LabVIEW does integrate with several revision control systems, and has graphical differencing and merging, but only in the professional version (we are given the Full Development system, which is one level lower).

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

[mluckham]

Originally Posted by Goldfire

This is my first year involved with FIRST (joining other mentors with more experience) as the programming mentor. We have team of 30-40 students, of which about 15 are interested in programming. They range in programming experience/knowledge from nothing at all to halfway through AP Computer Science. My personal experience is quite deep in C/C++ and non-existent in LabVIEW. I have no experience with robots of any kind.

I'm looking for suggestions of how to organize my students. Would it make sense to split into some who will specialize in LabVIEW and some who will specialize in C++? Should they all learn both? Is this an unmanageable size and should I work to encourage some to find other pursuits?

Assuming you are already meeting in the pre-season, I would recommend using the time to bring everyone up to speed with the tools available. We have decided to go with Labview - so have installed the Labview 8.5.1 (available free to FRC teams) on several machines and the students are independently working through some of the simpler tutorials.

Comparing Labview with C/C++ and Easy/C - only very exceptional students with actual C experience have found it easy to use text editor compilers such as MPLAB, while students with Visual Basic experience have some important basic knowledge (data types, etc) but because they all lack robotics/control system experience FRC is a total mystery until they are immersed in the environment for a number of weeks. Most of our potential programmers find icon-type programming such as with Easy/C more understandable, and are telling me their comprehension of simple Labview programs is similar ... although when we get beyond the simple and have to think of multiple things happening at once, they will once again fall off the track of understanding for awhile.

As we have been involved with FIRST for several years, we have the luxury of spare robot controllers/etc and have built several new platforms this fall with different drive systems plus having last year's robot available. Some of the programmers are reviewing the Easy/C code from the past couple of years, and implementing their own primitive control systems with the joysticks using Easy/C ... this is familiarizing them with draggable/configurable code blocks which has some equivalency with Labview. I understand from beta-Labview teams that the kit of parts this year will include a similar draggable icon library for Labview.

Some of the replies here talk about version control systems - that's too advanced for us, I will just have individual programmers work on Labview VIs independently (eg: joystick input and scaling, motor speed control with encoders, pneumatic arm control with limit switch) and convert them to subVIs, then have one or two of the programmers bring these subVIs together in the main program.

Hope this helps

[AustinSchuh]

Originally Posted by mluckham

Some of the replies here talk about version control systems - that's too advanced for us, I will just have individual programmers work on Labview VIs independently (eg: joystick input and scaling, motor speed control with encoders, pneumatic arm control with limit switch) and convert them to subVIs, then have one or two of the programmers bring these subVIs together in the main program.

I would argue that version control is good for your situation too. I use it for individual projects where I am the only guy working on things. That way, every time your code gets checked in, it gets backed up, and you can go back to that place in time if you run into a problem. I consider myself to be pretty good at programing, and I have still used revision control a couple of times now to figure out what I changed between right now and a couple of minutes ago that caused my code to stop working. It probably saved me a couple of hours. For me, it has gotten to the point where when I work on a piece of code and it isn't in a revision control system, I actually feel uneasy until I have put the code in a revision control system.

In your situation, I would view a revision control system as more of a "backup system" than something to do all the fancy merging and all that that revision control software also does. Your revision control system could even consist of a folder on the school's server that all your programmers can access that you zip everything up nightly, adding the date to the folder name, to back it up. That is all that most pieces of revision control software will do for you anyways when you are using binary file formats like labview (I'm assuming that labview uses a binary file format), since you can't merge binary files together unless you actually know how the binary format works and can teach the revision control software that.