Programming Team Size, and do they all do?

[Alan Anderson]

More than two or three people working on a robot's program is probably going to be hard to manage. I'd try to find other things for them to do. For example:

Give a couple of people the task of writing amazingly complete and useful documentation for all of the code that the team produces.

Have someone become and expert on version control systems (Subversion, CVS, etc.).

Start a configurable dashboard viewer programming project.

Divert some of your programmers to web site development.

[Guy Davidson]

Originally Posted by Alan Anderson

More than two or three people working on a robot's program is probably going to be hard to manage.

Originally Posted by geeknerd99

there should be one, at most two or three actual code writers.

This is what I thought. I too really didn't see a good way for more than two or three of us to work on the robot's code.

Alan, thanks for the suggestions. We'll be sure to set up some good version control system. I would think that you'd want the people who wrote the code to write the documentation, because they know best what it does.

What exactly do you mean by a configurable dashboard viewer? Also, which sensors and control methods do you suggest we learn how to use? Particularly for better autonomous and human control.

[BlackShadowFox]

I agree with Daniel Lin for only about 3 code writers but it would also be nice to have a system to clean up each others code and stuff like that. or even make it a competition between the 3 to have the best code. I don't know but as for you Daniel You had Chris check and clean up some of your code once or twice.

[Qbranch]

I am on 1024 and the software team captain as well as manufacturing coordinator. We use C and have 7 people on our programming team. I've found that everyone can have a purpose...

I have one guy thats awesome at Visual Basic 6... so, he makes rockin front ends that eat data off the dashboard port the robot passes back... mostly his tools are used for debug. He works closely with an interface programmer on the robot side that does the feedback going through the dashboard port (there are 8 user bytes that can be passed back, they usually operate on a rotation schedule so we get anywhere from 8 to up to 32 bytes (depending on update rate you're ok with) passed back).

Then, we have people who all have various parts of the robot... novice programmers work on the teleoperated period getting data from the OI... more advanced programmers take on different implements on the robot and write the drivers for them... this class of programmer also writes drivers for any new sensors we might encounter (camera two years ago, ultrasonics last year). The most advanced/gifted programmers and myself work heavily on the autonomous mode programming and any highly complex sensor drivers.

Anyone left over does cool stuff (extra features) for the robot... usually there isn't any one left for this... but this year we have a couple that want to try doing automatic rollover mitigation for the robot in case we have an unavoidably top heavy design.

For multiple codings to interface with single motors (i.e. teleoperated PID velocity control interlaced with rollover mitigation) overarching conditional structures are implemented to decide which control output to use based on the magnitued of 'decision indicies'... basically these values relate how dire the need is for one or the other algorithm to get at the motor. The fancier approach we're trying this year is wiritng algorithms such that their outputs sum to a final control output. That last part's still in R&D but expect it this year.

Anyhow... yes you can use a lot of programmers.

-q

[Alan Anderson]

Originally Posted by sumadin

I would think that you'd want the people who wrote the code to write the documentation, because they know best what it does.

That's exactly why you don't want them to do the documentation. They already know the purpose and intended usage of each routine, so they're not going to realize how important it is to explain the less straightforward details. You want someone with an "outsider" point of view to fully document everything, asking the coders to explain things that aren't obvious.

What exactly do you mean by a configurable dashboard viewer?

The OI's dashboard port lets a computer eavesdrop on the radio modem communication. There's a provided dashboard viewer program which shows all the relevant data, but it isn't necessarily in the most useful form on screen. If you can tie the dashboard feedback to a nice graphical representation of the robot, you might have a better diagnostic tool when testing the system.

[Robostang 548]

This year, the Robostangs programming division has a total of 9 members. But fortunately, we have several programming projects that extend beyond the robot so we can keep everyone busy. From scouting programs to custom IFI dashboards we have something for everyone to do. Only about 3 people actually program the robot. I did a lot of research with sensors over the summer so I already have a lot of code written for them. You can check out one of our projects we did last year, our robot simulator for our drivers, here:
http://www.chiefdelphi.com/media/photos/27481

This year we will be doing this project again only we will have it running on an xbox 360. We hope to be able to take it with us to our regional’s so other teams can take a try at driving our robot.

[AndrewN]

If you have a range of ages, you "pair" new programmers with experienced programmers. It's called "pair programming", whenever you write code you have two programmers looking at it as it's being written. One writes the code, the other watches and asks questions. Having to explain your code to another person helps clarify what you are doing and leads to less bugs. It helps transfer experience from more experienced to lesser. Either of the two people can be doing the coding and switch it around every hour or so.

You can fairly naturally divide the team up into "drive", "game mechanisms", and "autonomous". With two programmers on each task, that's 6. Another person (experienced) could be responsible for providing test builds and downloading to the fabrication team. Writing small pieces of code to test the mechanisms quickly without getting in the way of the other programming pairs.

It also helps if you can separate out last years controller for the programmers to work with on the bench instead of on a robot.

[artdutra04]

Have your extra team members (besides the 2-3 needed for the robot) work on various projects for your team; there are a lot of other programming-related things besides the robot. Have them learn HTML, CSS, AJAX, PHP, and MySQL and work on creating a custom database-driven CMS for your team's website. Once that's onlline, work on creating all kinds of cool back-end features for team management. This is great for 2-3 programmers.

If you still have programmers left over, have them learn Flash and ActionScript, and create a Flash-based version of the current FRC or FTC game, like these from 2005 and 2006:
http://www.chiefdelphi.com/media/papers/1606
http://www.chiefdelphi.com/media/papers/1751

[Guy Davidson]

Alan and Robotstang, thanks for the idea about the dashboard. We'll definitely try to write our own this year, and hopefully give it a useful GUI. We might mess around with the .NET framework that someone already created that's uploaded in CD White Papers. If we don't use one of those, we'll write our own.

Andrew, the pairing idea looks great, and sounds like something we will do. We're not sure yet how we'll divide responsibilities in the robot code, but we'll consider the way you do it.

Art, we're using Drupal right now, and don't think we really need a new CMS. But we might create a flash-based game simulator, or other creative projects.

Thanks everyone for your ideas.

[Gdeaver]

Programmers tend to go off on their own and totally concentrate on the "code". Mean while the mechanical teams are adding, dropping, changing motors, adding limit switches, and other stuff. At same time the control board is being fabricated and wired. The 3 teams tend to not communicate their changes. If there is a surplus of people 1 or 2 could be tasked with making sure the changes are communicated between the groups.

[Uberbots]

What im planning on doing is going over the basics with all of them, and then the ones who seem to get it, but not completely, will go off with someone else for the electrical stuff. I figure that people who know the intricacies of the robot controller will be easier to interface with when a wire snaps or the coders need to know a quick PWM (two very moot reasons, but it is too late at night to think of better ones).

I would have to agree, though, that having more that one main programmer even is very difficult to manage- unless you have the most talented one doing the autonomous code, another doing the user code, and another who does the general config of things (e.g. programming easier interfaces/frameworks). Getting the 3 to work together though would probably be the biggest challenge (=

[Guy Davidson]

Gdeaver, we hope to eliminate this problem by having twice / three times a week meetings between the build and programming leaders.
We will probably all be working on all code together, so that should hopefully make it easier to share, assuming it's well-commented. Which is a pretty big assumption

[shawger]

I think with this many programmers you have some great options not available to many teams, but you will have to figure out how to be organized.

You should definately use a source code control system like subversion or CVS. That way, multiple people can work on different areas of the code at the same time, and then merge their changes together. With proper commenting on each commit, this could also help as a documentation tool.

You can also create branches in a source code control system. Maybe there are two or three different ways you could solve a problem. Why not create a new branch for each way, try them all out, and see which one works best?

Also make sure you keep documentation on the code as you write it. Last year, I wrote the code and wrote the documentation afterward. Given that I was really the only one doing the programming, it wasn't a big deal for me. However, it took awhile to do, and with many people working on the code, everybody will need to know how it all works.