So our team is completely in the dark about using onboard pid loops on the motor controllers – we have nice SparkMaxes and TalonSRXs but we’ve always used pids almost exclusively on the Rio which isnt great… my question is which pid config would you use for each situation, what kind of overall schemes do you use? When would it be best to use the onboard current, velocity, position, motion magic loops? For a drivebase, an arm, an elevator, a flywheel? And then what do you put on the Rio?
You have a lot of questions rolled into one there. Is there a specific situation you are trying to solve or is this just a curiosity question?
More of a curiosity question. Do most people use the loops on the mcs themselves, or do everything on the rio, or a cascaded combination? I assume its case by case, of course. I’m just trying to see what others do so when it comes to planning our own control schemes I sort of know if I’m doing something normal – we’ve used a number of cascaded control systems on the rio and primarily current loops on talonsrxs.
Okay. I can really only speak to ladders and drivetrain. For our ladder we ran position PidF on a Talon. For drivetrain you generally want to cascade a Talon velocity pid outputting motor power on each side with whatever velocity generating program you want to run on the rio, be it a gyro angle pid or a path follower, but it really depends on what you need to do.
What leads you to this particular conclusion?
1 Like
Basics - Control loops for a single motor can run a lot faster in a motor controller. I believe there’s some options (new this year?) for motor controllers to work together for multiple motors. I’m curious how well that will work on CAN busses with a lot of traffic.
The RoboRIO can run control loops for multiple motor controllers, but only at 50 updates per second. That’s pretty slow in the motion control world of physics.
50Hz is perfectly acceptable for the vast majority of FRC mechanisms - 20ms is short compared to the timescale of most of the important dynamics. Also recall that the update period of slaved controllers is generally 100Hz (unless you do custom CAN timings), so you’re often limited to that anyway in practice.
2 Likes
OP - The summary: RIO works fine, no shame in using it.
If we have an SRX/MAX available to do closed loop control, it often make sense to do it, if nothing more than to reduce processor load on the RIO.
This can be true, but is hard to justify across the board. As another point of reference: we run 20ms control loops at work regularly without issue. Sometimes you need 1ms, sometimes 10ms, sometimes 100ms or slower… really just depends on the behavior of the mechanical system you’re attempting to control.
That being said, erring on the side of caution with the faster controller won’t be an issue with proper design.
Personally, my thinking is that any SISO control loop should run on a motor controller. Anything more complicated should run on the roboRIO. The more you can offboard from the rio to individual motor controllers, the less rio processor power you’re using and cleaner your code is*. That being said, once you start getting into multiple input/output systems like a drivetrain or other differential mechanism, it’s nicer to have one central device controlling everything instead of multiple discrete devices working in parallel.
For most control loops you’re running, the increased loop speed falls under “nice but not necessary.” The exception to that is current limiting, where there’s a huge difference in response between a 20ms and 1ms loop. Using the internal current sensing in the SRX also saves you from polling the PDP for current data that frequently, which will seriously load down your CAN bus. Then once you’re using an SRX for current limiting, there’s little reason not to use its onboard closed-loop control ability.
* IMO just setting gains at startup and sending setpoints is nicer than running PID on the rio and having to route the output form that to the respective motor controllers. It’s certainly much cleaner than if you would choose to “roll your own” controller instead of using something pre-built.
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.