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?
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.
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.