From your experience, what is the ideal size of a programming team? Last year my team had 2 people, but we have about 10 people interested this year. Is that too many or is it possible to find enough to do for everyone to stay busy? Thanks in advance!
10 is probably too many. Depending on how complex you plan on making things, anywhere between 2 and 5 is probably plenty. We had 3 last year.
Our programming team is about 5-6 kids. I think at times it is hard to keep everyone doing something, especially when something specific needs to be accomplished. Everyone sort of has to crowd around the laptop and watch the one person at the keyboard, and it can be a little (actually, a lot) boring.
One good way to break it down would be to have part of your programming team working on programming the EDUBot or the Vex robots. They’re very similar to the full size robot, and it’s a lot easier to test code on them since you don’t have to worry about smashing into anything. That way you can have two programming teams that work together on different objectives.
Our programming team has never had more that 3. It seems that with any more you will start spending more time on coordination and less time on productivity. I’m not saying its impossible, but you will have to focus much more on keeping everyone together. I have told several interested people that i would be happy to try and teach them some programming, but we need effeciency when build season comes around and we already have enough experienced programmers. There is only soo much to do on a project this small.
I would put down 1-4 as the ideal number.
I’d say maybe 1, but 2 or 3 is far better. One experienced programmer can get things done by themselve, assuming you get the robot to them with enough time remaining (and let’s face it, that doesn’t often happen). Therefore with a team, more can be done in a short time. However as soon as people start hanging around the computer(s), you’ve lost your effiency as a team.
My programming team is a combination of programmers/custom electronic people. We have 8 people in the group. Some of us work on code, others work on encoders. With a large group, we tend to get off task and do random things like shout quotes from Zero Wing. But it’s great having a large group, we usually get lots of things done.
One person.
Really.
In the offseason there should be multiple people learning the ropes, and all members of the team should of course understand how the other subsystems work (doubly so for programming), but the robot code is rarely complicated enough to allow for any reasonable task division.
The only case where I’d consider more than one would be if you had a co-processor for some specialized function that required a lot of code.
Last year I was pretty much “the camera guy.” If there’s another component with as much complexity as the CMUCam this year, it might make sense to give a person or two that task to work on separately.
Very true, but there are ways to break it up a bit. Last year, we had three people. One got autonomous (we didn’t use the scripting, so it was slightly more involved), one got drive controls, and one got arm control. By breaking it up, we were able to each make our part more complex and advanced than if one person had to do all three.
Last year, my team had 6 programmers: 3 experienced, 3 n00bs. We divided into three sub-teams of 2 (one vet, one n00b) and each sub-team worked on a seperate programming section. One team worked on the CMU Cam, one team worked on other sensors (encoders and gyros) and one time worked on a dead-reckoning autonomous.
one is all that is really needed and there should be several on the team that should know C and basic componets of the default code and the code you have on your microcontoller just in case. When you have more than one person then the code can get messy if you aren’t using uniform variables. But everyone here im sure uses good programming practices 
Our team this year has about four people, which seems to be a good size.
Team Fusion had one engineer (me) and one student during the 2004 season. In 2005 we upped it to the two of us from 2004 and 4 additional students. In reality, one experienced person (engineer or really sharp student) and two or three people wanting to learn about programming are what you need. Since I was always about 1.5 - 2 hours late each night of the build season, I broke our programming team last year down into semi-scouts. I put one person with the mechanical team, one with pneumatics, and one with electrical. When I got to the shop from work we would meet to discuss what surprises the other groups had added to the robot without letting us know in advance.
Now that is a dang good idea. People who’s only job is to keep track of robot changes which affect programming (IE, everything). I suddenly have a use for the 6 people who want to learn programming…
One person is the way to go, unless you have a nice RTOS setup, which you hopefully don’t, since it’s a great way to waste memory on the PIC. If your robot testing grounds are away from where you build the robot, though, make sure you have someone check on your programmer every so often - returning at 2:00 am one Sunday morning after 8 hours of programming, I found the rest of my team concerned that the robot had run me over, which it had, although without injury.
<off-topic>Ha ha, that reminds me of when I was almost hit by our robot’s knock-down arm. A very close call (it would have injured me if I got hit). :ahh: </off-topic>
So it seems like the “special number” is 4 people…is there any way I can get more involved? I hate telling people they can’t do a certain job that they want to do. I happen to agree though, any more than four would be bad as people would just end up sitting around and/or making more work for us.
What limits the number of programmers you have is mainly the complexity of the code. I can see 6 to 10 or more programmers working fine without interfering with each others’ work if the robot is properly built. Must haves for a large programming team? Encoders and a gyro. Just to name a few, here are some of the things that you could add to your robot’s code to make it a bit more interesting:
- In autonomous mode, have a function that moves the robot to a specified location on the field, and turns to it face a certain direction.
- Use that same piece of code outside of autonomous mode to turn a tank or four-wheel drive robot into an omnidirectional robot.
- Instead of doing empirical analysis, use your robot to keep track of the acceleration with respect to the input value, and make it modify your motor outputs to linearize the top speed with respect to the input value.
- Create a waypoint-selection system and “go to” button interface so that, in the dying seconds of the game, when your drivers are weary and blurry-eyed, they can press a button and let the robot get itself back home for those extra 10 points.
- Create a full-fledged navigation system in which the robot is aware of its current location on the field, as well as the location of any static field objects, so that it will turn to avoid bumping into walls, goals, etc. when going from point A to point B.
- For multi-jointed manipulators, add position sensors (potentiometers, optical sensors, etc.) and convert awkward polar motions into clean, intuitive linear motions so that when the operator pulls back on the joystick, whatever the arm’s holding moves straight
up - no circular motion. - Use scripts (or, if you really want to get fancy, arrays of instructions as well as a script processor) to automate tasks, both in and out of autonomous mode.
We have had only one programmer in the past, now we have 5 interested people.
The size of the team depends mostly on resources. If you have a few PCs and robot controllers then you can support a larger team. If you only have one laptop it will be hard to get more than a handful of people involved. A team of one person, unless you have no choice, is ridiculous. Just because the person with the most experience can’t be bothered to integrate source from a few less experienced people is not fair to the rest of the team. What happens if the ivory tower alpha geek gets sick and can’t make it to the competition? I would say you need two people minimum, on a larger team appoint one tech lead for design and integration.
Sean, we have plenty of PCs and this will be our second year in FIRST so we will have two controllers.