Sensors, TalonSRX vs Roborio

Technical Programming
1

Hi all, I have been wondering what is the benefit for using the talonSRX built in close loop and not the PIDController class (connecting the sensor to the roborio).

We had a hard time using it last season (probably becauae of bad encoders that we will replace) and now I need to convince ppl its still better (cause I know it is).
We are using Java.

Thanks in advance :slight_smile:

2

You can connect the encoder directly into the TalonSRX and it lets you process the output of the encoder in a much higher rate, thus having better accuracy.

3

Ok, but I need some based arguments in order to prove my point.

Correct me if I am wrong but the PIDController class is at 20ms, dont think we need it to be any higher(?). (Its the limit of the talon built in pid anyway isnt it?)

4

Last year we had an application where we used a large amount of PIDControllers, each taking up some of the resources on the RIO. Probably wasn’t the best solution, since we actually reached a point where the jvm would crash due to low memory. However, the talon srx let us offload that pid logic onto the talon and free up resources.

5

The rate requirement for your control algorithm is highly dependent on the system its controlling, and how quickly the system has to move to a desired state.

Remember too that you will also have sample limits on the sensor (encoders get wonky near zero speed) and on the command to the actuator (standard hobby PWM can only update the motor 5 times per second, no matter how fast your control algorithm is running).

The Talon PID runs at 1ms - I presume the sensor sample and output update are in the same loop. This gives you more bandwidth in your control algorithm to deal with more sensitive systems or aggressive tuning gains.

6
  • Modularity/separation of function:
    Using the Talon SRX internal closed loop is literally pushing all the logic and implementation details of how the motor does what you ask it off into a black box. All the options and controls that 99% of teams are going to need are already built into that box, and the default settings seem to be good enough more often than not. - **Reliability: **
    Those short, snug fit factory encoder cables are (again, for 99% of teams) going to be more reliable than the encoder cables which end in Dupont (0.1") connectors. The higher the speeds you need, the more this will be so. You also don’t have your tight motor controller loops occasionally interrupted by long calculations you’re doing on the RoboRIO (unless it gets so long as to activate the watchdog timeout). - Simplicity:
    The code you need to write to drive an SRX to do 99% of tasks is going to be less than half the length of making software PID loops. That not only makes your code easier to write, it makes it easier to inspect and maintin, and may even help keep the weight down :]. - **Scaling: **
    The RoboRIO has ten DIO channels explicitly plus another ten or so in the MXP port. Each quadrature encoder uses two of these ports, an there are also likely other limit switches or other sensors and possibly even a few digital outputs. On the other hand, using the SRX closed-loop, the number of inputs you have is essentially limited by the number of PDP slots; you can have analog, encoder, and limit switches for each and every one of up to 16 motor controllers - and the CPU load is mostly taking place in those black boxes, not inside your RoboRIO.
7

The Roborio would run control loops at the stated 20ms in a perfect world but it rarely does. If you do some sampling you’ll see it bounce around that timing. But the talon is 20x faster. This will significantly affect the performance of your control loops.

It’s also important to consider roboRio CPU usage. For instance, in autonomous you might be running motion profiling. That requires control loops on both sides of your drivetrain with additional overhead if you’re integrating a gyro. You might be controlling a turret with another control loop. You might be controlling a hood angle with another, and a shooter wheel with yet another. Perhaps an intake arm position with another. If you’re running a swerve drive you would need 8 control loops at a minimum divided between driving your wheels and steering them.

We have run out of RoboRio cpu the last couple years. It’s easy to do if you have other things going on. Sensor feedback to the dashboard, telemetry recording to the roborio itself, and teleop velocity control of your drivetrain are just a few other things a lot of teams use.

Some teams rewrite the entire robot framework in order to improve it to minimize their control timing and try to run their loops in the 5 ms range. It much easier for our team to meet our performance requirements and still have the roborio cpu where we think it needs to be (in our experience, keep it below 80% for best results).

Team 971 might have some more info, they’re pretty heavily invested into maximizing the control system’s performance.

8

Thank you all for replying!
I will keep those tips in mind and hope we will return to use the TalonSRX close loop.

If anyone got anything to add it would be much appreciated :slight_smile:

9

I think one thing that’s worth noting is that in a drivetrain application, or any other time you’re going to run PID with a master/slave config, the update period for the slaves is 10ms. So, you’re not really running the control loop at a kilohertz.

The PIDController class is a perfectly reasonable solution, if you do not want to use a Talon. As was stated earlier, it is not that hard to saturate the computing power on the RoboRIO (the processor kinda stinks, tbqh), so offboarding as much processing as possible to peripheral devices can be a good idea.

Unfortunately, the Talon API is a bit of an obstacle, as it is constantly-changing and very bloated, so I’m not sure I’d recommend Talon PID to a beginning team, given the simplicity of the WPILib PIDController.

10

Weren’t we also trying to run velocity PID on top of position PID or something?

11

While the 1000hz loops and sensor integration might be nice at times, I think the talons real strength is in motion magic. For the vast majority of teams that dont have the time to craft perfect control loops, throwing motion magic on an arm or an elevator usually gets you most of the way there with minimal effort. Unless you are really starving for more flexibility in your code, its hard to justify something else besides the talons.

12

Amm looks like a bad contradiction. Can a CTRE dev confirm it? isn’t changeable?
Seems like something worth opening an issue over.

13

You can edit the frame periods, but there’s not much point. The difference between a 1khz and a 10ms control loop isn’t that big.
That being said, we use Talon PID for everything. Why?

  1. It’s easy to set up. We just say “here are the constants, slave these motor controllers, and here’s the control mode” and it just works. We can set up multiple Talon PID loops on each controller fairly easily, and indeed we do for drivetrain applications.
  2. We get Motion Magic, which is great for anything that needs to move smoothly. It does have its limits, such as on our elevator (where the inertia of the elevator makes it difficult for the control loop to stop easily on the way down) but they are pretty easy to work around.
  3. There are a lot of features. Automatic limit switches, absolute sensor wrapping, current limiting, etc. make it easy to just run everything on the Talon. The RIO CPU usage is just a bonus.

The one place where I find Talon PID lacking is drivetrain path following. The Talon implementation is currently confusing and difficult to use once you want to add a gyro. We’ll be attempting to move to RIO-side path following for 2019.

14

Worth a discussion perhaps, but there are some legit reasons to have it set up that way. CAN bus load, latency, etc. can be problems. Additionally if the master is changing at 1ms, you technically do get 1kHz control, it’s just that it takes 10 loops to servo your slaves to support the master. Might reduce ability to correct for large disturbances, but not by that much (as others have mentioned).

15

Does anyone know of a good public github that shows an example of a drivetrain using the Talon closed loop controls?

it would be nice to see someone else implementing simple tasks like drive straight for X distance, or turn X degrees using the built-in talon loops.

16

We’ve continue to shy away from using the Talon pid and motion profile control for the drivetrain just because of how it’s implemented. It’s confusing once you start trying to add the gyro cascade loop. We use the velocity, motion magic, and pid controls for all our other mechanisms though, those are simply fantastic.

17

By default, the WPILib PIDController class runs at 50ms (20 hz). The Iterative/Timed Robot periodic methods run at 20ms (50 hz). The rates are configurable for PIDController and TimedRobot, but not IterativeRobot.

18

I won’t make any claims that it’s a good example, but I do think we had a relatively simple distance/angle command for our drivetrain last year, based off of the motion magic control mode. We didn’t actually use this command for competition, in favor of using entirely motion profiling, so I don’t believe that the motion magic parameters were ever properly tuned, but the command worked for our early testing.

Here’s the relevant code: https://github.com/FRC3238/2018Robot/blob/master/src/frc/team3238/commands/chassis/RunMM.java

While I’m here, I might as well throw in my two cents on the titular issue in question:

I’ve never been a fan of the PIDController class, because to me it seemed more complicated than necessary. Why have an interface to get the output power when you should be able to (in simplified terms): 1) poll the sensor, 2) pass sensor value to pid controller, 3) get output power from pid controller, 4) set motor power? In my opinion, this flow of logic is much more simple than that which is required by the PIDController class. This really isn’t that big of a deal, since the only real leap in complexity is the use of a simple interface, but it is something that I had a bit of trouble understanding as a brand new programmer.

For a few years before we started using onboard TalonSRX PID control, we wrote our own simple PID class that worked essentially as outlined above. In 2017, though, we began wiring our encoders directly to the Talons, and I personally loved the ease of use. Excepting weird bugs from persistent settings on the Talon, we found everything fairly easy to use, and the documentation in the software reference manual provided help for almost anything we wanted to do. I’ll specifically mention that their documentation for the velocity control mode made a lot more sense to me than the documentation for the feed-forward term in the PIDController class, at least from the perspective of a then ignorant noob to closed-loop velocity control.

Most of the advantages of onboard talon PID control have already been mentioned, but one that was really helpful that I don’t think I’ve seen mentioned yet is the ability to tune PID parameters on the fly with the roboRio web dashboard. I know that the PIDController class has some of this functionality with shuffleboard, but we enjoyed using the persistent settings to go nearly the entire build season without ever specifying the PID constants in code, and simply tuning the parameters as needed. We would often use things like roughly tuning the parameters for our shooter velocity PID loop in 2017 without ever having to stop the shooter spinning.

With regards to motion profiling, we found that our paths were precise enough even without a gyro, even running the points through the talons without doing any adjusting for acceleration or anything fancy like that. Our paths were repeatable, though not necessarily accurate. We never reached a level of confidence that would’ve allowed us to specify start and end points and expect our robot to end exactly there. However, it was good enough for us to have movements that would work almost every time, so long as they were tuned first.

I can definitely agree that this isn’t the ideal scenario, and if I hadn’t just graduated, I’d probably be spending my time working on a better solution incorporating a gyro and more of the concepts in the drivetrain characterization whitepaper. That being said, I think that motion profiling onboard the talons is good enough for almost anyone that doesn’t already have a working solution.