The Mukwonago BEARs

As lead of the Firmware team this year, one of my first major decisions that I needed to make was that of the programming software and language we would use. Last season I was the only programmer and was provided only one option—C. This year, however, two rookies are on my team, and as a part of my sub-team, they had a say in what we were going to be doing for the next six plus weeks.

This year we had two choices. On one hand (being C/C++), we had the comfort of a familiar language. We knew its limits and how to get things done. However, the other hand (being LabVIEW) was a graphical display for easier (or so we initially though) drag-and-drop style programming. We figured that the easier to program with, the better.

After a few discussions (and perhaps arguments) we finally decided unanimously to use National Instruments’ Laboratory Virtual Instrumentation Engineering Workbench (aka LabVIEW).

For the first few meetings, we played around (and got it installed) on multiple computers and got to know a bit of what we were doing. We got our first program working (of which we were very, very proud) and have thus used parts of it as a starting block. The Electrical Hardware team watched a few tutorials with us too.

Then we started to program. We went through and were going pretty good. We figured stuff out slowly but surely with only a few minor bumps along the way. The biggest annoyance (initially) we had was not having a functional robot for testing our code for real.

After awhile, we discovered our need for a “sub VI.” For anyone with any experience with programming, a sub VI is like a function. Basically, it takes a block of code and puts it in one block, making the main program easier to read and keeping it much more organized.

We dragged on. After awhile I started wishing we hadn’t gone with LabVIEW, but it was much too late to turn around and start over from the beginning. The new big annoyance for me was not being able to merge two LabVIEW files together—with a simple C++ file, you can merge files together when you update and commit with Subversion. But since LabVIEW doesn’t save its files in text, it is therefore impossible to work on more than one computer concurrently.

As time went on, we started adding more and more code to help minimize slipping. One of our more recent projects, dubbed “Operation Snowbunny” by yours truly, was a function that would basically assist the drivers on going in a straight line by fixing up all the motors. This was quite easy to program into LabVIEW because all of the upper math functions were already in the program. Therefore, it was as easy as (pretty much) drag and drop.

However, some things have been difficult to put in. Some basic things that we programmers take for granted (like the use of global variables) are not easily done inside of LabVIEW.

Although most of this is rather frustrating, there will always be pros and cons to everything. Luckily, we have had a great mentor to push us through the hard times and is constantly finding us things to do (rather than spending a few hours with a button maker) to help improve Mare Crisium.