Programming Retrospective

[JohnGilb]

So, you LabVIEW using teams... after another great season of competition, we have some downtime to take a look at our code and think about what went wrong and, well, what went right!

As for us...

Right:
-Key constants on the robot were read from text files on the cRIO, making it easy to modify robot parameters without re-downloading code
-We achieved a high degree of encapsulation, allowing for easier code reuse and distributed workloads in the programming team
-We finally started using source control, which allowed for distributed work as well as all the other benefits

Wrong:
-Our system architecture had sensors "owned" by the systems that used them the most, but sometimes other systems needed to know their state too. This led to some messy compromises.
-Our logging system didn't capture enough data to debug an issue after-the-fact.
-It was difficult to test individual systems, or even individual components (such as turning a single valve off or on) without running debug code, making it difficult to verify repairs or changes to the physical robot.

So, what have you learned this year?

[plnyyanks]

This year, I'm particularly pleased with our code. I go into some detail about how it works here. If you want to take a look at the code, you can find it here.

[Levansic]

Originally Posted by JohnGilb

-We finally started using source control, which allowed for distributed work as well as all the other benefits

What did you use for source control? We had many issues trying to combine efforts of multiple programmers.

-- Len

[JohnGilb]

We used SVN, integrated with Windows through TortoiseSVN. The 2011 version of LabVIEW has a diff and merge utility, so you can actually get a lot of work done. That being said, it's still easier if people are working on different VIs, so our high degree of encapsulation worked out well in that context.

[Levansic]

I looked at using Git, with TortoiseGit, but ran into problems setting up a local Git server. Source control will be a summer / off-season task for us.

Our team has typically had one student who was a main programmer, and quite a few who joined that subteam for a day (and quickly wandered off). Now we have a few students contributing to that effort, and source control is becoming more critical.

Our "solution" this year was Saving a new version of the project and all touched files, every time something major was added or changed. This didn't work that well, in practice.

-- Len