|
|
|
 The hardest resource to come by in FRC is the one you can't buy: a well-trained, experienced, well-intentioned, dedicated mentor. - PayneTrain [more] |
 |
|
|||||||
|
||||||||
By: Tom Bottiglieri
New: 01-07-2010 01:33
Updated: 11-01-2011 02:26
Total downloads: 1342 times
Code for Team 254's Robot - Onslaught
Here is a snapshot of 254/968's robot software. This is the last check in we had at the Championship Event. There's a few parts that might be a bit messy, but I'd rather get it up here than plan to clean it up and forget about it.
The software was capable of scoring 3 balls in auto, kicking 5 balls in auto, entering/blocking the tunnel in auto, crossing multiple bumps in auto, and a bunch of other cool stuff.
Feel free to post questions or comments... I'd be happy to elaborate. If you want to re-use parts of it for your robot... go for it!
Attached Files
-
Team254-2010Code.zip
Team254-2010Code.zip
download file
uploaded: 01-07-2010 01:33
filetype: zip
filesize: 64.16kb
downloads: 1340
Discussion
view entire thread
10-07-2010 01:55
Pat Fairbank
Re: paper: Cheesy Poofs Robot Software 2010
Thanks for sharing! I love looking at other teams' code to learn new tricks.
Out of curiosity, what led to the decision to use a separate singleton class to hold all the sensors, actuators and logic instead of putting them in the class that inherits from IterativeRobot?
I really like the constants class and how you can read and save constants from/to a file. I'd definitely like for my team to adopt this, although I'm thinking of using preprocessor macros to ensure existence of constants at compile-time and avoid the (albeit negligible) performance cost of associative array lookups.
The auton command lists are really cool, too.
22-10-2010 21:35
Tom Bottiglieri
Re: paper: Cheesy Poofs Robot Software 2010
|
Originally Posted by Pat Fairbank
Thanks for sharing! I love looking at other teams' code to learn new tricks.
Out of curiosity, what led to the decision to use a separate singleton class to hold all the sensors, actuators and logic instead of putting them in the class that inherits from IterativeRobot? I really like the constants class and how you can read and save constants from/to a file. I'd definitely like for my team to adopt this, although I'm thinking of using preprocessor macros to ensure existence of constants at compile-time and avoid the (albeit negligible) performance cost of associative array lookups. The auton command lists are really cool, too. |
Sorry it took so long to get back to you. The robot stuff was put in a separate class to split it up from the competition logic. I like the idea of the robot being it's own thing, with something else twisting the knobs and switches. (The Robot actually needs to get poked with a handle() function to update all of the control logic.. I probably should have spawned a thread to do this rather than having it driven by the IterativeRobot callbacks, but oh well)
The persistent constants were super helpful. We were able to modify the file it lived in via FTP and update stuff on the fly. Crazy useful while testing/tuning. I'd love to see something like get baked into WPILib.
view entire thread
Tags
loading ...