Team 2337 - 2012 Rebound Rumble Code

[kenavt]

For the first time, Team 2337 is open-sourcing our competition code for our Rebound Rumble robot, the Admiral. Any comments and questions are welcome.

Code source on GitHub: https://github.com/Team2337/2012ReboundRumble

For more information on robot performance: http://www.team2337.com/robots.html

The robot CAD can be found on FRC-Designs: http://www.frc-designs.com/html/CAD_2012.html

More pictures of the Admiral can be found here: https://plus.google.com/115608715549316219693/photos;

GitHub handles LabVIEW files as strictly binary files, so to actually view the code, one must download this whole repo and view it on a local installation of LabVIEW 2012.

A couple of code features:

• An autonomous that reads scripts (with its own language) placed via FTP on the cRIO.
• All logic is contained inside the Periodic Tasks.vi, with control data passed to Periodic Tasks via local variables
• Simple shooter speed control
• A basic vision program mostly copied from the Rectangular Target Processing example
• 'Cheesy drive' - a form of arcade drive - provided by FRC 33 (which was based on work done by FRC 254)
• An intake logic system used to suck balls in one at a time, and queue balls out one at a time

[apalrd]

I looked through the Auton code. Could you possibly provide an example of what a script looks like?

[avanboekel]

Can you explain how the cheesy drive works. I have only tried tank and arcade in the past.

[Zach O]

Originally Posted by apalrd

I looked through the Auton code. Could you possibly provide an example of what a script looks like?

Here's a copy of the auton scripts. I can't tell you when they're from in the season, but they work. The top line is a description of what the auton does. I'm sure once Colin checks back in he'll explain a little about the format of the files.

http://zcry.me/RrCj

[Zach O]

Originally Posted by avanboekel

Can you explain how the cheesy drive works. I have only tried tank and arcade in the past.

I can't explain the LabVIEW part of it, but I can tell you how it works controls-wise. One of the sticks controls the forward and backwards drive, and the other stick will control turning. So your two axes are separated. I believe we have it in our code where if you're not going as fast on the forward-reverse stick, you'll get sharper turns.

[Woolly]

I'll just do a quick copypasta from Twitter for this:

Originally Posted by Woolly4 on Twitter

@Team2337 Hm... that command based autonomous looks pretty clever If I do say so myself. Though, could you clarify what poops.vi does?

[Zach O]

Originally Posted by Woolly

I'll just do a quick copypasta from Twitter for this:

poops.vi "poops" out all the digital IO states onto the driver console. It updates live with the robot, so you can see the IOs change as you go. We were having a lot of issues with our sensors at the beginning of the season, so we made this VI for debugging purposes.

It looks like I'm going to have to review filenames before we publish them next time

[apalrd]

Originally Posted by Zach O

I can't explain the LabVIEW part of it, but I can tell you how it works controls-wise. One of the sticks controls the forward and backwards drive, and the other stick will control turning. So your two axes are separated. I believe we have it in our code where if you're not going as fast on the forward-reverse stick, you'll get sharper turns.

The turning power is proportional to the forward power, and added/subtracted to the forward power. If the forward power is 0, the turning power is sent to the motors. This provides better control at high speeds, and with varying speeds.

[Woolly]

Originally Posted by Zach O

poops.vi "poops" out all the digital IO states onto the driver console. It updates live with the robot, so you can see the IOs change as you go. We were having a lot of issues with our sensors at the beginning of the season, so we made this VI for debugging purposes.

It looks like I'm going to have to review filenames before we publish them next time

Maybe reviewing them would be a good idea, but as long as you put a comment in it explaining what it actually does, it's at least worth a good laugh.
I mean, in our code, the logo for the vi that runs ball collection looks like a flux capacitor for no apparent reason.

[kenavt]

Hey guys, sorry - I had family over today, and frankly I wasn't expecting as much interest as was displayed.

I was intending to post example scripts, but I didn't have access to any - which I was planning to remedy next week. However, I took the scripts from what Zach posted and pushed the ones we actually used this year to GitHub, under the "Autonomous Scripts" folder, as well as a quick Readme on them.

For a quick overview, the way the a function works TYPICALLY follows the formula:

commandFunction(relative, start type, start param, end type, end param)

So, for instance, the function:

intake(relative, label-end, shootOne, t, .5, intakeOne)

Will follow the end of a label('shootOne'), lasts for .5 seconds, and is assigned a label ('intakeOne').

Hopefully this helps.

[apalrd]

Reading over some of the scripting system, there's quite an elegance to the entire system. I do like it a lot.