Re: Programming Team Best Practices
 

I remember that we had a huge whiteboard that we would "pseudo-code" on before writing it to the bot, we made sure that we had photos, so not only did we have comments in the code, we had reference of the creative process that went into it.

Re: Programming Team Best Practices
 

Food for thought: Software Design by Contract

http://www.cs.ucsb.edu/~bultan/cours...s/Contract.ppt

http://cs.olemiss.edu/~hcc/papers/sesec02final.pdf

http://en.wikipedia.org/wiki/Design_by_contract

Re: Programming Team Best Practices
 

We use Subversion. It works great! Here is a link to a workshop I have done explaining how to setup a SVN server. You don't need a super computer. Just about any old machine will work.

http://rar.meyermat.net/workshops/index.html

Attached is a document that explains how to use LabVIEW with TortoiseSVN.

-Hugh

Re: Programming Team Best Practices
 

Thanks to all of you who have posted so far, we have already started putting some of these recommendations into place. I'm also interested in finding out how other teams manage their programming groups especially during the early parts of build season when they don't have a new robot to work on yet. They are working on a test board now with several different sensors and the Kinect to practice with. Any other ideas about how to keep them away from the video games and focused would be appreciated as well. Again, thanks for everything so far. Good stuff!

Side note: chopsticks worked well with cheetos, a little tougher with hot wings though. Gotta work on that.

Re: Programming Team Best Practices
 

Butter's said some great things about preparation, which is a good morning/afternoon of day 1 activity.
At the moment we plan to have our programmers work with our design team for the first couple of days, just to make sure they know what sensors we need and where so they can incorporate it into the design and not be added in via duct tape and string at week 4. At least in my experience, fabrication, electronics, and design has a skewed view on what programming can do, so by being there you could potentially stop them from going forward with something that will be incredibly difficult to get to work, but also get some ideas out they wouldn't think of otherwise. Also, logical proof-of-concept VIs are a great thing not only for documentation for the design process, but usually can also be dropped right in the robot code later if the team decides to go that route.
Not to mention, in the early days you can usually work on basic drive code for both teleop and kinect hybrid, and maybe even test it if you happen to have an older robot with the same style of drive-train you plan to use.

Oh, and I think tongs would work well with hot wings, especially if you can somehow lock them down like a pair of vice-grips.
Note to self: Hot wing vice-grip tongs. Get on that, along with the nachobot.

Re: Programming Team Best Practices
 

Mountain Dew for the students, coffee for the mentors! Add a white board and you are in business.

Well, I reckon it takes a little more than that. We put a lot of time into the design stage using basic flow-charting and message sequence diagrams. Our robot firmware is multi-tasking using the VxWorks message libraries to communicate between tasks. This makes it easier to separate the design and the work into isolated efforts (drive, arm, wrist, claw, camera, ds comms, autonomous, etc) with defined interfaces (the messages) to the rest of the system.

HTH

Re: Programming Team Best Practices
 

Make sure all of the programmers know the electrical side as well!! This is extremely important. We are taking the time now to have our programmers learn all the electrical components because they need to know the system that they are programming before they can program it. Our programmers are literally going through the same training as the electrical students.

Re: Programming Team Best Practices
 

Our programming team has more than a few programmers. As soon as there are more than 2 programmers project management system becomes critical in the tight First schedule. After a near disaster in 2010. Our lead programming mentor implemented the Agile development methods. I definitely saw an improvement in product development and delivery. Our programmers are a scrumin. For 2012 I tried to apply the scum method to the mechanical build. Started out OK but as the pressure mounted things kind of broke down. I'm mostly at fault. So far I have not been a very good task master. It's one of the things that is at the back of my mind all the time. What went wrong, how did it get off track, what do I need to do different this year. How I communicate to the students Is my main focus. Effective communication is my main goal. The students rated my performance last year. One of our college student mentors did it. I'm trying to roll their evaluation forward. Every First team should implement some form of project management style. What works for one team may not work for another but, each team needs to develop their own system.