[Luke Pike]

When I programmed the robot this year, my process went like this.

First, the team decided what they wanted the robot to do. It was a very specific process, by the time we were done we had a list of all the features our robot would have, roughly sorted by priority. This is what the robot would do and nothing else.

While the design and mechanical teams were doing their thing, I would give input on the feasibility of programming a particular feature of the robot, whether I could use these sensors to control that thing to do this, etc. Of course, sometimes they have to do it a certain way, and I'll just have to work with it. Once the teams had finalized what the final devices were going to be for the feature(of course this might change and usually does), I would begin programming it.

The first thing I do when programming a feature is to think really hard about how I would do it. I'm talking like pacing around the shop deep in thought hard. The advantage of this is that I can catch problems before I even start coding. I usually go through multiple ways of doing it, and finding all the disadvantages and potential bugs. Once I have a good idea of how I'm going to do it, then I start to code. I test individual pieces as they are completed, like sensor reading, processing, and the like. LabVIEW is really great for this part, because I can run it on the cRIO and still get the front panel values.

The first time through it almost always fails, but that's to be expected. After running through it over and over again, I find the bugs and squash them. Sometimes it's a really stupid human error on my part, sometimes it's something that a sensor or part can't do and you have to find a different way. In the end, it gets the job done, sometimes in a completely different way then when I started.

This is the way I personally programmed this year. You can do it mostly any way you want, as long as it works for you and your team.