I’ve recently stepped in as the software program manager, and was wondering what other teams do to develop software. Our current process is write code, load code, watch robot spin around, scratch head, re-write code, repeat.
I work on a military rotorcraft fly by wire flight control system, and have some background in software requirements management and design. We don’t code, but are responsible for pseudo-code, system integration, and system testing. We are currently CMMI level 3, and trying to get to 5 this year. For those who don’t know what I’m talking about, it’s a system the government will soon require contractors to be certified to, and it shows that we document changes, measure our performance, etc.
I’m wondering what other teams do, ie does every change in code result in a new version number? Are old versions kept, no matter how small the change? Do teams perform specific tests once the robot is loaded with new software?
While this isn’t the most exciting topic, I think it is important that the kids learn the importance of documentation, since it is part of what engineers do.
So what do other teams do for software development?
well, this is our 2nd year as a FIRST team, but this is my first year programming, and im the “manager” of programming.
we’ve created a couple (well, a lot) of documents on “desgin” of the programming. First we created the REQUIREMENTS document, which the whole team can, basically, edit (but they dont…), to tell us programmers what they need programmed. (So they cant say, the day before ship date, oh, btw, we want these switches programmed for the such-n-such so they limit this and that…)
then, we have the DESIGN document, which has everything from the REQUIREMENTS doc, (waterfall effect!), with IPO (inputs, processing and outputs) described in them. this only programmers can edit
finally, we have the TEST document, which lists how we’re going to test to see if the code actually works. (for now, this will also serve as a test doc for the whole robot… simply because there’s no other test doc and this one has little boxes saying “PASS” or “FAIL”…)
for autonomous dealings, we’ve made some flow charts, excel docs, and the like, as we found necessary…
we also have an online version control system, but… we don’t yet have strict rules as when it’s a new version. (however, we have unstable versions and stable versions)
hope that helps and other input accepted,
~Stephanie
We don’t use version numbers as such, or a formal version management system. Each day’s work is archived in its own subdirectory, so we can go back to a known state of the code if necessary. Offsite backups (on Flash drives) are made of especially “functional” versions.
Nice, organized work. Probably it’s just what our team overlooked- we just try to get a piece of code working, then take another bit of code…
well, it’s not that bad if you take our numbers into consideration- i’m actually the whole programming team(well, there’s the programming team manager, but I hsven’t seen him for a while, and anyway- aside from clickimg the program button and doing some simple arithmetic calculations he can’t do anything of value- he doesn’t know a bit of C and/or robotics programming );
an example for this unorganized work is my function to calculate the angle of the joystick. it took me almost two days to get it working- first i tried to print floats using the %d command, then forgot that the atan(x) function outputs in radians, the i noticed that my algorithm was dumb… :o
if you want to avoid such situations-
Since I’m pretty much it, except for the mentor helping me… my system is pretty much: compile, load, debug, reload… etc.
Every day or two I submit the code to a svn server running on one of my computers, working .hex files are saved when I add a major feature (So if something gets really screwed up, I can load one of those, and keep the rest of the team happy)
It works out nicely… I have around 3 copies of the code on seperate computers, (laptop, server, desktop) plus a copy on my flash drive… so its pretty hard for me to loose all the code.