RobotBuilder Subsystems with multiple PID loops

We used RobotBuilder to generate CommandRobot java code for Ultimate Ascent 2013, with a gyro in a DriveTrain PIDSubsystem for horizontal angle feedback and a gyro in an Elevator PIDSubsystem for vertical angle feedback.

During build season we also implemented encoder feedback for the drive train, but we couldn’t figure out a clean way to include both the encoders and gyro as PIDControllers in one DriveTrain Subsystem.

RobotBuilder only allows one PIDController per subsystem, and no nested Subsystems, so we removed the encoders for this season. However, I’d like to figure out a good way to handle this for next year. Any thoughts on how to implement a CommandRobot Subsystem with multiple PID loops in RobotBuilder?

Mark Kadonoff
Programming Mentor
JMHS Warbots Team 620

Robot Builder is great for quickly coding common patterns. For uncommon patterns (like the one you describe), you’ll have to modify the automatically generated Java/C++ code yourself. If your team is new to the language, looking at how one PID controller is implemented by the generated code is very helpful in figuring out how to implement the second.

Ziv, a vehicle with PID loops for translation and rotation seems like a common pattern to me. Maybe RobotBuilder can be enhanced to include additional Subsystems. Thanks.

This sounds challenging whether you use Robot Builder or code from scratch.

A PID controller takes an input and an output. In this example, you have two different kinds of inputs (gyro and encoders) feeding to a single output system (the drive train).

Is this really a common task? I’d be very interested how others have combined PID logic within a subsystem.

We used RobotBuilder to define the chassis subsystem and the sensors (two encoders and a gyro), but then added the PIDControllers ourselves. You can see more details in the following thread:

We have often implemented drivebase position and heading as feedback-controlled parameters in autonomous. I can only remember one year that we made it available to the driver in teleop, as an optional “bulldog mode”. It was occasionally useful when trying to hang tubes on the Rack & Roll spider legs in the presence of strong defense.

The way we did it, the PID computations were separate, and their outputs were mixed to send to the motors in the manner of arcade joystick control. For the RobotBuilder scheme, perhaps the “speed” and “steer” can be considered distinct subsystems that don’t actually control motors, but instead just set global variables. The final “chassis” subsystem will have a background command that controls the motors based on reading the variables.

If you are seriously limited in your control system design by arbitrary limitations imposed by an autocoding tool or framework, then maybe the autocoding tool or framework is not the correct way to write the code you need.

Basically, you should just write the code manually. The code itself is only a few lines long (including the PID control math) and should be small enough to fit in a single function.

I’ve always seen the RobotBuilder and command-based frameorks as large inefficient beasts which impose so many design limitations on algorithm code that in almost all cases you are better off without them.