Organizing many programmers

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