Quote:
Originally Posted by DjScribbles
I'm thinking about doing some house-keeping during the off season to decouple the game and controls from the robot class, which should make it easy to spawn off autonomous helper functions and autonomous routines that don't all have to live in a single file to gain access to the robot parts.
|
Yes, something like that is necessary once your robot code gets beyond a moderate level of complexity.
You may want to look at the
WPILIB command based programming model which does that. You define every action as a class which extends the command class. You can define commands (or groups of commands) to run from button presses or other triggers, or to run in autonomous. We wrote our code in Java this year, using the command model. We ended up with 14 different commands in our 7 shot autonomous (some were called multiple times). Many of those commands were shared with our teleop code, which really simplified things. Some of our commands were things like spin up shooter, shoot a frisbee, move to pickup position, turn pickup on, drive to position, etc.
It also provided ways to manage hardware by defining subsystems, which group related hardware. A command can require a subsystem, which says it's the only command that can use that hardware. It can also require a subsystem but then be defined as interruptable, which says that another command can be scheduled to use that hardware, and the first will end when the second starts running. This is especially useful in teleop, where the operator may press multiple buttons before a command finishes, and gives the program a way to determine the correct way to proceed.
New this year, WPI provided
RobotBuilder to make generating the code templates for the command model easier.