[James Tonthat]

In my experience with FIRST, I would actually say a lot of the FRC code is written by students.

I've been meaning to get our team to write some sort of white paper. I'll get them to document their offseason work and hopefully can contribute to the code base and knowledge of programming. I don't think we'd be posting any specific code because it probably wouldn't be helpful to other teams but probably more of what concepts we come up with for autonomous with visual aids/diagrams to help programmers visualize how things should work.

I've been on both mechanical and programming, and what I tend to see with programmers is the disconnect between what is expected to happen (how it's coded) and what actually happens (and how to correct the issues.) Hopefully we can address these issues, in said WP. ("I'm outputting PWMs of 5, shouldn't it be moving?" "No, it's not enough power.") Others before me have said, it's important for the mechanical to understand programming but it's also important for programming to understand mechanical.

When it comes to programming autonomous and human controls, I think the most benefit comes from understanding how to create human controls. A lot of the issues (and loss of potential points) I see during a match can be resolved with a change in how the controls are set up and intuitive they are. There's also the issue of programmers making the robot too intuitive to drive and taking control away from the driver. Drivers are smart, they'll figure it out. Maybe this is more a industrial design type issue but usually in a team, it rests on the electronics/programming team. This area more than any other programming area can make or break a team (in my opinion.) We had some awesome controls in 2008, (one joystick, one driver). I'll definitely include a section about controls design.

Edit: I did a bit of thinking, our whitepaper will be about controls and not really programming itself.