Team 279's 2009 Code [LabVIEW]

:yikes: I’ve finally been able to post the code from this year :ahh:

We only used the Basic Robot Main file from the Basic Project and did not use the independent autonomous file so i’m not going to post the whole project file. The Atlanta code is fully commented and there is a sub VI called autonomous matrix that is also in the zip file that is used in the code.

[edit]
The Basic_Robot_Mode vi was changed to include the robot mode variable output.
[/edit]

[edit2]
The buckeye code was thrown together from scratch thursday night at the regional because our code that we had made didn’t work so it looks pretty terrible =)
[/edit2]

[edit3]
Feel free to use the code in presentations or in an educational fashion but please say its from Team 279.

Buckeye Code and Commented Championship code is in Buckeye_and… .zip, uncommented version of championship code in 279_Atlanta… .zip
[/edit3]

Buckeye_and_Commented_Champs.zip (148 KB)
279_Atlanta_No_Comments_Version.zip (92.1 KB)


Buckeye_and_Commented_Champs.zip (148 KB)
279_Atlanta_No_Comments_Version.zip (92.1 KB)

Cool, thanks! I hope more teams start posting code, too.

I agree, though there are two sides to this. In the competition, traction control (though it hasn’t been proven beyond reasonable doubt) could be a huge advantage to robots that have it, and providing the code to do it would be gracious but sometimes the code is pure-custom and giving it away for anyone to use… i just don’t think many would be up to that

May I ask, what are you using the matrices for? How is it being used?

Of course you may ask, that’s why i posted it =). They are being used in our autonomous system. The system was developed by a teammate to take the autonomous time (the unbundled variable at the top of autonomous enabled) and compare it to the first column numbers. Each of those numbers is a point where we want the drive direction/speed to change. The second and third columns are, respectively, the X and Y values that we want to change to.
The time values are in seconds, between 0 and 15.
X and Y are values between -1 and 1 which simulates the joystick input to the Arcade drive VI
In order to switch between the 12 matrices, there are 6 switches on the driver station that are added as can be seen in Autonomous Disabled to derive which matrix is to be used. The matrices on the front panel are labeled for each position they will be used in. The programming team debated over what to do with an unwanted combination and decided that it would do exactly what we did at Buckeye: Go forward.

if you would like to know anything else or if i missed something, please don’t hesitate to ask.

One big advantage of releasing your code (IMHO) is that you’re able to take whatever is released and use it the next year due to the rule about COTS software. This is a particularly useful thing if you create a library out of useful generic things that aren’t specific to a particular robot. Granted, one could easily recreate a lot of things, but that just seems like wasted work.

Libraries would work for the teams who write the code in C, however, we used LabVIEW and only the autonomous uses a custom VI and even that is quite small and easy to reproduce. The entire Buckeye Regional program we used was redone in <30minutes do to a massive fail on my part. Definately easy to reproduce, granted we didn’t use a camera nor any special sensor driven processes [traction, robot avoidance, etc.] which would take longer, but either way, As i said before, releasing code would be nice but not all teams are going to.

True, if you don’t modify the default stuff extensively, then there isn’t much advantage of releasing stuff. But for anyone who did, I would say its a bigger advantage (we had 4 independently steerable wheels, so the default code didn’t work particularly well for that… :slight_smile: ).

Of course, we did ours in C++… but I think LabView allows you to create reusable components, so thats probably roughly equivalent to a library.

It definately would help you guys more than us. our autonomous stuff is the only advanced work that would help us but it was easy to redo. are you guys going to put your code up?

It is up. See my signature. :slight_smile:

Of course, I haven’t actually put up a separate notice on Chief Delphi, but maybe I will at some point.

Ah I see. You should post here, it’s more visible =)

Ok, you’ve convinced me: http://www.chiefdelphi.com/forums/showthread.php?p=849360#post849360 :stuck_out_tongue:

Sweet. hopefully more people will post theirs too.

I need to talk it over with the Team Coach, I will probably release some of our code. Its a Crab Drive system, so I consider it pretty interesting.

Will look more in depth at your code once the finals are over.

But the Matrices sounds like an interesting approach to the Autonomous Commands

Rookie Year is keeping us busy for sure!

did you use LabVIEW or C++?

LabView all the way.

I will learn C++ in the off season…

Sounds like a plan. I might end up with one less time waster this summer so i may not have to wait until next year to learn =)

Here are a couple pieces I guess…

Here was the first version of the autonomous… I have created something different, but it was something to get us moving at our regional.

The comments are kind of lame, but they are just there to assist in teaching some other guys on my team about the code.

Autonomous Independent
http://i6.photobucket.com/albums/y238/txnhockey3/AutonomousIndependentd.png
Periodic Tasks
http://i6.photobucket.com/albums/y238/txnhockey3/PeriodicTasksd.png

What is the I2C used in the periodic tasks?

Devantech Digital Compass…

I believe to access multiple I2c modules i will need to open device 1, read dev1, close dev 1, open dev2, read dev 2, close rev2 and loop that sequence. Since the Devices used different addresses so they can use the same port.

We just didn’t have enough time to code. Never enough time is there?