Re: Programming Team Size
 

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

Re: Programming Team Size
 

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.

Re: Programming Team Size
 

We have had only one programmer in the past, now we have 5 interested people.

Re: Programming Team Size
 

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.

Re: Programming Team Size
 

Sean, we have plenty of PCs and this will be our second year in FIRST so we will have two controllers.

Re: Programming Team Size
 

I would say that this can vary from your creativity.

First is about a lot more then just robot programming, if you're creative enought you can make all kinds of stuff.

Last year we updated our picture to our website, and we had to add our team number into each picture.

Then I've just developed a software that would do that, it helped a lot our website team, I know that photoshop can do that, but we don't have Photoshop, and were's the fun on using it right ?

And the one really great thing we created was the Autonomous Control software, wich is a graphical windows software that can be used to control the Robot in the "arena" and it would just create the code for our autonomous implementation.(I must release the source code to everyone, but some menu stuff are in portuguese, it's not 100% translated.)

And you can always try to use first a real programming lesson for the students. You can have some methodology to follow, like RUP or MSF, this kind of stuff that involves lot's of documentation and discussion before actual coding, this could be done in a larger team.

The big challeng will be to convince a 15 years old not to play with the robot joystick and develop programming documentation. or if he's a programming crazy, to make him stay away from code, and use only Word;

Re: Programming Team Size
 

My team actually has seven Programmers on our team this year. I believe this is our fifth year as an established FIRST team.

And I agree with you, Squall. We do have a hard time not playing with the robot joysticks, but keeping away from the Anime viewing on the laptops and drawing on each other's papers with notes. We tend to procrastinate, but we get the job done, as our CMUCam actually recognized the green, and accelerated forward for a few meters and just stopped...

Re: Programming Team Size
 

That I would be very interested in. I've done autonomous abstractions (in the form of "scripts"), using primarily the preprocessor. But I have yet to make an external tool.

Re: Programming Team Size
 

I solo'd this last year for our team in a few days. At most, you'd need like 2 people - any more than that the marginal costs of adding people (extra source control, etc.) would far outweigh the gains of having one more person working. Besides, a FIRST robot doesn't need a lot of code, probably only 1-2.5KLOC with an autonomous mode.

Re: Programming Team Size
 

On a FIRST robot, one or two. I was the only member of the software team last year and it looks like the same this year as well.

Re: Programming Team Size
 

Last year we wrote a nifty tool called ARCAMS(autonomous robot configuration and monitoring system) that allowed you to graphically create autonomous scripts and then upload them to the RC EEPROM over the serial port. It also allowed realtime graphing and datalogging of just about any robot parameter you can think of.

Re: Programming Team Size
 

Our team overall is fairly small, numbering about 15 fairly commited (we're rookies). Kinda unfortuneately, we have 5 people doing programming. I don't know how tough it will be to keep them all working.

I know at CTY I started work on a little space shooter game written in Java (C is not my first language so to speak (no pun intended)). I worked with another guy and he was less confident about the programming. Unfortuneately I ended up doing most of the programming (not that I'm not competent, but we could have gotten more done).

I Guess it'll be my responsability to give out tasks, and whip those sorry recruits into line (*pirate-like, drill-sergeant-reminiscent growl*).

Just my 2cp (again).

Re: Programming Team Size
 

Ways to involve more people in software:

Build simulator boards with components and controllers from previous years. Use them for training and for testing concepts. Multiple simulator boards can allow multiple programmers to work at the same time.

Use the simulators with "mock ups" to validate concepts while the mechanical team is building the real robot.

Learn to use the simulator in the Microchip IDE. The simulator allows you to "run" code on your PC, including the ability to provide sensor input. This is a great way to check basic flow of execution because you can single step the simulation. Once the code is on the robot, all you have is print statements and the dashboard.

Organize the software project (the MicroChip IDE project) to make it easier to have multiple contributors. Don't have everything in one or two source files. Break the different aspects of the program into separate source files. This allows multiple people to make changes at the same time (without overwriting each others changes).

Implement a version control system to keep track of changes. A simple way is to take "snapshots" of your project file directory on a regular basis (daily, hourly, any time you make a big change, just do it). Learn to use a diff (difference) tool to compare different revisions of the same file to see what was changed.

Implement a backup system so that failure of a hard drive etc. does not result in the total loss of source code. When taking a "snapshot" (see above) make second copy to different computer, a pocket drive, zip disk, floppy disk, SOMETHING!

Write a separate diagnostic module to download to the robot to aid in debugging and testing. The code that actually runs the robot is not always the best for trouble shooting a problem or performing a system test to insure that all sensors, motors, etc. are working properly

Team new members with experienced members (for the whole development cycle). Train for next year while developing for this year.

Assign software team members to act as the interface point with the other design groups. That way the other design groups know who to go to with a question. That person should attend design meetings of their assigned group to make sure that needs of software group are being met by the design. (ie do we need a sensor, where is it going to mount, how many do we need, what kind should we use)

Assign software team members to become the team expert in various areas, there is so much information no one person can possibly learn everything.
Microchip IDE/Development Environment expert
Operator Interface Expert
Robot Controller Expert
Victor, Spike, Radio Link Expert
Sensor Expert(s)
....

Assign a member to document the interface (how does everything hook up). When a wire comes off, people can lookup where it goes.

Have a design document which describes how each major "component" will work. If you can't explain in words how something is going to work, you shouldn't start writing code. This document can be the source code file. Describe in words how the function or module will work. Later add code between the descriptive text lines. Voila - clearly documented code that someone else (or you 3 weeks later) can understand.

Software development can be a "team sport" if we work at it.

Re: Programming Team Size
 

I think the best thing to do is to have one or two veteran FIRST programmers (if possible, i.e. not a rookie team) and two or three people who are learning. This way when your seniors graduate you have the people who are learning becoming the veterans the next year.

In my FIRST experience (4 years with three different teams), if you have only one student (or in certain cases, one adult! ugh!) writing the code, then you don't get people very interested in the programming. You also have potential problems when mechanical decides to change the design of the robot 16 times in one day and overloads this one kid with programming demands.

Any more than 5 people on the programming sub-team and you run into problems where no one understands the code, and software version control becomes a problem.

Re: Programming Team Size
 

last year it was just me, this year it is me and a college student. It helps to have atleast one person with decent knowledge of code structure and one with a decent knowledge of the bot, subsystems sensors, custom electronics etc. If one person can do all of that then you only need one. If not then break it up.

Any one who says no more than one person can program this simply means your code lacks comments and structure, someone with little knowledge of the code should be able to follow your changes with little effort. 2 experienced programmers should be able to work easily side by side