What is the benefit of PIDs? Which use cases?

Technical Programming
1

Bit of a rant here. We’ve been trying for days, weeks, this season, and in past seasons, to get a handle on using PIDs. For what seem to be relatively simple use cases like turning to a certain angle, or centering on a Limelight target. Both of which we had working fairly well without using PIDs. We use similar logic, of basically, ‘as we approach the target, we reduce the power’. It seems to work fairly well. For example, we can reliably get centered on the limelight target to < 0.50. Half a degree. Without PIDs. Even for a long range shooter at 30ft I think that’s only a couple inches off, which is probably negligible, because you’re probably going to have at least that much error just from ball spin, balls drifting in the air, etc.

So where’s the benefit of using PIDs in these use cases?

We use % motor power for our drive, using Talon controllers. So the range of inputs are around 0.20 (minimum power) to 1.0. Maybe there are better options. But once I realized that the output from the PID loop for this Limelight example is producing a tiny error, 0.5 - 5.0, as you get close to being centered, and that we’d then have to convert that into a meaningful adjustment to our % power, it doesn’t seem worth it. We can do something simpler, like stair step the power down at certain thresholds, and get the same result.

Also, we’ve never gotten PID tuning via the Shuffleboard to work, either. I’ve run it in Test mode, added the PIDSubsystem to the Shuffleboard, and the widgets just randomly disable, or grey out and don’t take the inputs, etc. More lost time.

But it seems like there’s so much discussion, articles written, documentation, etc. on the benefits of PIDs that we’ve spent/wasted so much time trying to get them to work. And now I’m wondering why, and lamenting over that lost time. I’d love to get to using Trajectories for nice looking, efficient paths in auto. I’ve skimmed through the tutorial for that and see that they use PIDs, so some understanding is probably helpful.

I’ve been assuming we’re going to use PID to maintain speed for our shooter. Maybe that’s a better use case.

But so far, trying to get PIDs to work, has only been a great deal of lost time, with no benefit. Anyone have a similar experience, or can convince me of the benefit of continuing to try to get them to work?

Also, FYI, I have minimal electrical and mechanical experience. I’m more of a pure coding mentor. I’ve tried to learn some of the wiring, electrical, motor control, etc. from a other mentors who are MEs with experience in electrical controls, but still, there’s a vast void of stuff I don’t know.

2

I can only speak to PID from an ME perspective, but it sounds like you’re overthinking it.

At essence, any control loop is just measuring current instantaneous position (using an encoder maybe), comparing that to desired position (your setpoint) to get an error (setpoint - current position), and then doing something with that error until the error goes away over time (preferably quickly with minimal to no oscillation).

The control loop you are using is just a modified P loop, since all a P loop does is reduces your control input proportional to the error (as you get closer, slow down).

If you are having trouble with the implementation of PID (which should be built into the Talon) or tuning of PID, you’re going to have to do some research. It can be more of an art than a science, though there is some new characterization stuff that can reduce that burden.

6 Likes
3

When someone says “PID”, there are cases where you don’t use the I term or the D term. Your example of “as we approach the target, we reduce the power” is proportional control, or just the P term in PID.

Moving towards a target using just P control in some situations won’t get you exactly to your desired target. For instance - if you’re trying to use your limelight to lock on to a goal, using just the P term can produce inconsistent results. If you set your P gain too low, your robot will get close to centered but won’t get all the way there as the motors stall. If you set your P gain too high, the robot will overshoot your target and then possibly oscillate until it gets to a point that the motors stall.

This is where your I term comes in. It’s a collective summation of your error over time. If you get your P term just right, your I term will be able to move the robot to that centered state by slowly ramping up (or quickly, depends on your gain) the motor power to get it to the desired position.

It seems that your issue is just getting your gains right. Start with a P controller and get it close, and then start doing trial and error with a PI controller (keep the I term small - around 0.005 or lower). You’ll get there.

Here’s a good illustration: https://en.wikipedia.org/wiki/File:PID_Compensation_Animated.gif

11 Likes
4

You may be inadvertently doing proportional control anyway. If you’re reducing your power linearly compared to the error (difference between your current position and the target position), this is essentially P control.

It looks like you’ve already identified that 0.2 is your minimum power for the drive. If you’re simply adding this to the output to establish the minimum, this is the same thing as the feedforward term you’ve seen in documentation.

PF control [(target position - current position) * Kp + Kf] is satisfactory for most applications in FRC. Adding I and D terms may improve performance depending on the mechanical system, but for someone starting out in controls, I would avoid them (especially I).

3 Likes
5

We are essentially in a similar place as you all, so I will defer most questions to more intelligent people on CD. However, as to the why, I think the shooter example is a best-case scenario for PID. You have one motor (probably?), and the force acted upon it to slow it down is generally predictable. You want it to maintain speed, and the motor controller in a closed-loop is an excellent way to do so.

Our drivetrains are significantly different. Some people prefer open loops or just a PD closed-loop system for them. Also, professional systems frequently ramp their PID as you seem to in your example (perhaps with proportion). You can actually do this for each constant in the equation.

Whatever you do, the purpose is simply to get to the setpoint as quickly (and smoothly) as possible without overshooting, undershooting, or never getting there in the first place. For drive systems, some people determine they do not need the integral (or maybe at times, the derivative) to do so. However, for some things, we need to be certain that the device will achieve what we want at exactly the time we want it. Sometimes, PIDF (F is the feedforward prediction) is the only way to safely and reliably accomplish this.
Last year, we used PID to rotate to an angle, and are currently working on adding it to our vision tracking code. Like with your team, we are learning as we go.

As for wasted time, I know time is short for us always, but I feel understanding PIDFs will be a valuable skill for our members. Perhaps it is a waste (it does take a lot of time to tune the system).

Good Luck.
~Mr. R^2

6

This is conceptually-correct, but I think a slight clarification on terminology is needed:

In most implementations, kF is multiplied by the setpoint prior to being added to the output. This is because most PID implementations are intended for velocity control of permanent-magnet DC motors, for which this is an accurate compensation for the motor’s “back-emf.” In WPILib terminology, this corresponds to the kV gain of our feedforward objects.

A constant feedforward term (that opposes the direction of the motion) is almost never referred to as kF - the WPILib feedforward objects refer to this as kS, and most smart motor implementations do not provide innate support for it (though it can be easily added through their “arbitrary feedforward” functions).

1 Like
7

Yes, a full PID is very often overkill and not necessary. I also try to stay away from PID libraries and the PID on the motor controllers. They’re more opaque and difficult to debug. Its also tricky to add specialized features to PID to solve problems. My unpopular opinion is that PIDs are highly over used in FRC.

The best code is the simplest code which solves the problem. I nearly always start with bang-bang control and then add features as needed. Usually this does not result in a PID, but instead something highly specialized for the game.

As an example lets use vision tracking the outer goal.
Bang-bang is accurate enough for the outer goal when close. No more complication is needed. When far from the target we need to bang-bang slower to prevent overshoot. Linearly interpolate the amount we move based on how far we are from the goal. Use the area of the target in the image to easily gauge distance from target.

I find that often PIDs are too rigid, too opaque, and more complex than necessary for most FRC applications. Start with bang-bang, then logically add features to increase speed, and consistency. You’ll often arrive at something that performs quite well, and is easy to read and debug.

(Do use a PID for a shooter wheel though, there is so substitute for a PID in that application)

1 Like
8

if you want to get started with PIDF or motion magic on talon SRX’s this whitepaper is a good resource

9

I concur with @Knufire - I believe this arguably is PID control. Just with I and D gains equal to zero. So take hope, you are already closer to success than you think.

Here’s the mental model I like to use:

Feedback Control is a system design strategy where you use some form of measurement to calculate a control effort for a mechanism on the robot.

Concretely for FRC, this measurement is usually a sensor, like an encoder or limelight. The control effort is simply “voltage command sent to a motor”.

It’s not technically a “pure software” concept. It just so happens that the measurement+math+control effort thing usually involves using a processor, which means it often falls to the software subteam to design, implement, and tune it. But keep in mind, it’s not really a software question. Just a question that is frequently answered with software.

When people talk about “PID”, they’re referring to a particular subset of the various maths that can be done on your measurement, to calculate that control effort. It’s not the only option, and (if done carefully) a more “custom” or “homebrew” solution like you describe can be quite effective.

I see your woes as consisting of three major components:

  1. As you correctly identify, feedback control is not always required. In fact, the less of it you need, the more reliable your robot will (usually) be.
  2. There’s a lot of other stuff that has to be right, before you can even say a PID algorithm can be “right”.
  3. Your ability to debug and interpret the time-series information will make or break your success

To (2) - as a few examples, the sensor and control effort have to be aligned (usually, positive control effort results in increasing sensor measurement). The sensor and motor have to be robust mechanically, and (fairly) linear in response. The mechanism has to be controllable (ie, not too fast, or not too slow).

The takeaway from all the above: there’s a lot of stuff, totally unrelated to any real feedback control topics, which will inhibit your ability to properly get feedback control working.

This may also be helpful? Let me know if it’s not, it can be changed :slight_smile:

All this being said: If the robot works, it works. No need to “add PID” to make it better. Best I’d recommend is to try some PID’s on that shooter wheel in the offseason. Shooter is one of the easiest PID systems to tune. Specifically, tune F, then P, then D, then I. Put some balls through it, see how it responds to disturbances. Do it at a time when you can play around and get a feel for what all the knobs do.

10

ok, thanks all for the responses, info, and encouragement; really appreciate the helpful community here

11

Isn’t that proportional control?

2 Likes
12

This is the best video I’ve found on PID control explaining what is going on. https://www.youtube.com/watch?v=JFTJ2SS4xyA

13

Don’t. Not this build season. Focus on refining the code you have and then learning more after build season/comp season is over.

The main application that I think PID’s are useful in FRC are for drive-trains in autonomous.

Unfortunately, autonomous driving with motion profiling is far out of reach for many teams. There are many good reference out there, but they are so black-box that people sometimes have trouble implementing them.

Edit: I have removed a portion of this post that was relatively unimportant, but misused terminology, so it ended up being more confusing then helpful. Click the small pencil in the upper right corner to see the original post.

14

Although I’m all for advanced motion controls in FRC, I was following up until here. Could you iterate on this point a little more?

1 Like
15

WPILib is a black box?

https://docs.wpilib.org/en/latest/docs/software/advanced-control/trajectories/index.html

4 Likes
16

For Error Code Xero, we control elevators, turrets, or arms the same way. We use a trapezoidal speed profile generator to create a motion plan. We use a PDVA (feed forward on velocity and acceleration) to follow the generated profile, and we use a pure PID (generally just the P term) controller to hold a mechanism in place after it moves. With this software all in our base library and the process for tuning documented, we can generally get an arm, turret, or elevator tuned and working reliably in about 30 minutes. Even though this approach may be overkill for some applications, reusing the code and doing things the same way every time means we are getting pretty good at it. It saves time that we can spend on our automodes instead.

Just my $0.02 worth.

1 Like
17

This might be a hot take, but…

Yes, in this case. There is a lot of math behind the system that isn’t explain. Without a fundamental understand of what is happening, errors and bugs can be much harder to solve. I don’t think that additional theory needs to be taught by WPILIB. It’s a lot and calculus is a beast that needs to be carefully handled. To black box it is smart, but brings up difficulties.

18

If you’re willing to dig a bit deeper: Is there anyone you have in mind who should be teaching it?

This thread (and the many others like it) show there’s a knowledge gap: Students see the advantages of closed-loop control techniques, and want to get started, but apparently don’t have the resources (textbook, mentor, simulation, or otherwise…) to bite it off successfully.

Context: One of my self-ordained summer projects was to submit some PR’s to the FRC readthedocs to help cross this gap. Looking for early feedback and guidance from the community on what is and is not desired.

1 Like
19

I was vague here, my fault. With more powerful motors, we can easily assume physical properties like instantaneous acceleration or using voltage control. This makes non-PID controls better.

20

You really don’t need to know any calculus to use PID or the wpilib trajectory resources. By far the most important base knowledge is basic programming competence and a familiarity with dimensional analysis.

5 Likes