[Greg McKaskle]

In my opinion, learning how to learn is the whole point -- of FIRST, of school, etc. So your description sounds pretty familiar.

Some days I know exactly what I'm doing and how to do it. Other days, I have no idea what solution will work and I begin by determining a system for knowing when I'm done, breaking the problem down into smaller steps, coming up with experiments where I will gain understanding, etc.

My suggestions are first to go through the example programs and tutorials, either alone, or ideally as a programming team. You may already know some of the stuff, but they should help to instill the basics since the examples don't do everything at once.

Next, I'd suggest writing totally different programs that perform math or draw graphics. They are easier to verify, they have some application to the robot, and they are sorta fun. This summer, on a long airplane flight, I rewrote a program for my kids. It is one of the programs I wrote when I first started working at NI and needed to learn LV. The first picture below is the basic one where I worked out the math, and the second one was where we had fun adding multiple pens, showing the disks, adding a camera capture, and making it interactive where they decide the speed and direction to move the pens.

Anyway, pick something that interests you or something that you wonder about. Plot equations that show how your robot will respond. Make a toy or a game. And when you find black-magic, feel free to ask questions here.

As for your initial question about programming the robot differently, my suggestion there would be to make a few subsystems and isolate them from the rest of the robot code. At some point, I hope to update the templates to better promote this idea, but the roboRIO comes first.

As a simple example of this, the vision code is now a bit more isolated. The initialization code is no longer in Begin and Finish doesn't close it. That code moved into the Vision VI. The camera control and communication are done through a few global variables. Even better would be to write a VI that updates the vision system's state. Anyway, the idea is that the rest of the robot doesn't need to not worry about the implementation and shouldn't change the camera settings directly. Instead, it should make requests of the subsystems and harvest results. This also makes it easier for a team member to own certain functions of the robot and expose them in a way for others to use, but not break.

Good Luck.

Greg McKaskle