: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.
The Basic_Robot_Mode vi was changed to include the robot mode variable output.
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 =)
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
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
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… ).
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.
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?