Clutter from autonomous

[DjScribbles]

So this is my second year mentoring FRC, and the second year where MyRobot.cpp has absolutely exploded through the competition season due to autonomous routines being added.

I'm curious if many teams out there have similar issues, if they've solved them, and how?

My personal thinking is that a lot of this stems from the robot class being extremely tightly coupled with the game and driver station elements, and forced into a cpp file with no .h backer declaring things. While I understand this is to make things simple for people to start out, it seems like a better way should be available (in the form of an example project)

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.

Thoughts?

[Joe Ross]

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.

[virtuald]

Typically, we split the functions of the robot into different classes/modules that implement a portion of the robot functionality. Then all you do in myrobot.cpp is things like "if joystick button 1 is pressed, call this function". This helps keep things more organized and easier to debug.

More importantly, it makes autonomous mode really easy to implement and easy to understand, since it's only manipulating existing objects, and not creating new functionality. Most of the time, the functionality is shared between autonomous and teleoperated mode, so we get extra testing for free

[DjScribbles]

I have considered command based, but I feel it's a bit too abstract for a teaching tool, even if it would produce cleaner code.

We do currently break our code down into classes (shooter, collector, pid control, etc), however my gripe is these constructs still live in myrobot.cpp

Our teleop is pretty simple, and an autonomous routine taken by itself isn't so bad, but the sheer volume of autonomous routines (5 at the moment, with 3 or 4 deprecated, and at least one more on the way) leads to a large amount of code if it lives in one file. Moving the routines into seperate files would require passing all objects in myRobot.cpp by reference, or creating a .h file.

[virtuald]

Originally Posted by DjScribbles

. Moving the routines into seperate files would require passing all objects in myRobot.cpp by reference, or creating a .h file.

Yes, that is the C++ way of doing things.

[MrRoboSteve]

Having tried all of the textual language approaches, I think it's easier to teach kids to program with the command-based framework. There tends to be less code on the screen, and kids can focus on one particular aspect of the robot without having to understand the whole thing. There's a class of state machines that you avoid.

The result also contains useful building block pieces that you can easily combine into different autonomous routines.

[DjScribbles]

After watching Brad Millers presentation at CMP, I'm starting to come around to the command based template.

Definitely something I'm going to give a try and see how the kids like it.