PIDController + Latency - related issues

[Alan Anderson]

Originally Posted by Agent ZeusChops

PID uses a relative setpoint and uses a graph similar to sin(X) after reaching the setpoint + someOffset. After that the equation becomes +/- offset and appears similar to the graph of sin(X) where the height is equivalent to the offset + setpoint. Theoretically, there are no issues with this AT ALL.

The issues here are many. Your theory appears to based on a badly broken understanding of what PID control is and what it does. Please stop trying to justify it until you have read more about how and why PID works. Here's a widely-recommended overview: PID Without a PhD.

I already gave you my comments about latency in the other thread.

I am fairly aware of your point that you made in the other thread Alan, however, the team that I was on saw no error correction prior to the Integral calculation. I don't know if that means that it was clearly tuned wrong or what, but that does certainly force an issue upon accuracy. Applying that specific PID to the shooter, which never corrects to get onto the set point, adding in a human-dependent interaction could create a larger issue. However, as Thad had mentioned yesterday, there could be a check that may prevent the issue.

[Alan Anderson]

If you are trying to analyze a system where you are controlling the velocity of a shooter wheel, you need to make sure that the process variable and set point are describing the same thing as the controller's output.

You can't just use RPM as the input and motor speed as the output. If you do that, then when the speed reaches the set point, the motor output will be zero. You either have to post-integrate the controller's output, or you have to reinterpret the PID as DPX. Among other things, that means the I constant in a velocity controller will have the same effect as the P constant in a position controller.

That is the reason your team found that you need Integral in order to get a shooter wheel to work. It has nothing at all to do with latency, or with the type of control device used by the driver, or with the graph of sin(x). Again, I urge to you to abandon this line of reasoning, because it is based on assumptions which do not match reality.

[Pault]

Originally Posted by Alan Anderson

You can't just use RPM as the input and motor speed as the output. If you do that, then when the speed reaches the set point, the motor output will be zero. You either have to post-integrate the controller's output, or you have to reinterpret the PID as DPX. Among other things, that means the I constant in a velocity controller will have the same effect as the P constant in a position controller.

I'm not sure what options are available in LABVIEW, but the simplest way to do this in Java, C++, and onboard PID with a Talon SRX is to just add a feedforward term.

To add feedforward (kF): remove all other constants, set the setpoint to a specific speed (I've heard 3/4 of max speed is usually pretty good). Then increase the kF until the actual speed matches the setpoint. From there, you can start to play with small values of P and I to get your controller more accurate.

[Alan Anderson]

Originally Posted by Pault

I'm not sure what options are available in LABVIEW, but the simplest way to do this in Java, C++, and onboard PID with a Talon SRX is to just add a feedforward term.

The built-in PID in LabVIEW is not like most other implementations. It uses the academic form, with a single overall gain and a pair of times for the Integral and Derivative parameters. There is no feedforward provided.

You can "roll your own" and make a PID controller using a more conventional form, including feedforward. It's not hard. Tuning a conventional PID is probably easier (unless you bring in a lot of math and analysis to compute the appropriate academic parameters based on the system's step response).

Feedforward only works well if the system is reasonably linear. Your system might always use a range of wheel speeds where that assumption holds, and it would be fine in that case. You should still be aware that you are relying on that assumption.

[Pault]

Originally Posted by Alan Anderson

Feedforward only works well if the system is reasonably linear. Your system might always use a range of wheel speeds where that assumption holds, and it would be fine in that case. You should still be aware that you are relying on that assumption.

This is mostly true, however a strong integral term is normally enough to make even a very non-linear system work, especially if you are only using a small range of the total RPM that the shooter is capable of. There probably are better ways to deal with this if you aren't happy with feed-forward, though.

Alan, I agree with your point completely. But The reason I added in latency was because the system is flawed by never receding back onto the 'setpoint' as well as the system requires that user input is given to launch the ball. I don't really care how the system is setup nor do I care to look too closely at how the code is formatted. I'm fully aware that this certainly creates issues upon 'defending my point' but the system does not appear to be consistent. I can say that the robot uses one motor for the shooter which is controlled by a PIDController. There is an encoder used on the shaft connecting to separate belts to drive the two axles with wheels attached. I can do a rough sketch of the design if needed, but the actual system should still remain with the receding pattern given by the pdf however the activation only happens for roughly eight seconds, maximum prior to shooting so Integral never has a chance to increase large enough to reduce the error correction (if I'm not mistaken, they're using something like 0.07 for the 'I' value).

Currently, their code is written in Java but I'm almost certain that the language wouldn't matter as both Java and C++ should have the same PIDController formatting.

Defending the point of latency is that there is no extra check, as far as I'm aware, that the system ever waits for the current speed to be around the setpoint forced into the PIDController prior to launching the ball. The launch of the ball is forced by the manipulator and they only receive controller vibration to notify them that they are 'at' the setpoint. Certainly, there wouldn't be an issue of latency if the system was setup correctly.

[Pault]

Originally Posted by Agent ZeusChops

Alan, I agree with your point completely. But The reason I added in latency was because the system is flawed by never receding back onto the 'setpoint' as well as the system requires that user input is given to launch the ball. I don't really care how the system is setup nor do I care to look too closely at how the code is formatted. I'm fully aware that this certainly creates issues upon 'defending my point' but the system does not appear to be consistent. I can say that the robot uses one motor for the shooter which is controlled by a PIDController. There is an encoder used on the shaft connecting to separate belts to drive the two axles with wheels attached. I can do a rough sketch of the design if needed, but the actual system should still remain with the receding pattern given by the pdf however the activation only happens for roughly eight seconds, maximum prior to shooting so Integral never has a chance to increase large enough to reduce the error correction (if I'm not mistaken, they're using something like 0.07 for the 'I' value).

Currently, their code is written in Java but I'm almost certain that the language wouldn't matter as both Java and C++ should have the same PIDController formatting.

Defending the point of latency is that there is no extra check, as far as I'm aware, that the system ever waits for the current speed to be around the setpoint forced into the PIDController prior to launching the ball. The launch of the ball is forced by the manipulator and they only receive controller vibration to notify them that they are 'at' the setpoint. Certainly, there wouldn't be an issue of latency if the system was setup correctly.

Latency isn't the problem here. Human reaction time from a touch stimulus (like vibration) is 150 ms. This team should be looking into a better way to control their shooter. If they can't figure out how to get PID to work (and trust me, there is a way to make it stop oscillating in a reasonable amount of time,it might take some creativity though), then they are better off just applying a set voltage and hoping that changes in the friction of the shooter, battery voltage, and other things that could affect the speed aren't too severe. They could also consider writing code that automatically shoots the ball when the shooter speed is at the right spot.

Also, I am going to ask that in the future you try to do a better job explaining what the problem is. You made a lot of assumptions about how most people consider a PID to behave. A normal PID controller in FRC does not behave at all like what this team is experiencing; most will stabilize to the point where they are either not oscillating at all or are the oscillation isn't noticeable. Taking the TL;DR from your original post:

TL;DR:
Objective: Determine if using a PIDController as a major source for velocity on your shooter is reliable.
Theory: Utilizing a PIDController as a major souce for velocity on a team's shooter is fairly unreliable due to unpredictable inconsistencies within latency during the teleoperation period.

This is not a general PIDController problem. This is a problem with how a single team happened to tune their PIDController, along with the fact that they tried to rely on their drivers to compensate for the oscillations instead of having code do it automatically.

[plnyyanks]

Originally Posted by Alan Anderson

The built-in PID in LabVIEW is not like most other implementations. It uses the academic form, with a single overall gain and a pair of times for the Integral and Derivative parameters. There is no feedforward provided.

For those curious about how the LV PID constants work, I'll quote a previous post of mine explaining it...

Originally Posted by plnyyanks

If you take a look at the implementation, it explains how the time constants relate to the traditional ones.

Here's the overall function:


The P component (Kc * error):


I [(Kc / Ti)integral(e)]:


D (Kc * Td * d(error)/dt ):




So, if you take a simple version of the formula like below...

Then:
Kp = Kc
Ki = Kc / Ti
Kd = Kc * Td

Pault;
That certainly makes liable sense then. I think Thad did have a solution if the case is such that they tuned the PIDController incorrectly and they don't want to spend a lot of time accounting for the differences. Thanks!

[ozrien]

Originally Posted by Pault

I'm not sure what options are available in LABVIEW, but the simplest way to do this in Java, C++, and onboard PID with a Talon SRX is to just add a feedforward term.

To add feedforward (kF): remove all other constants, set the setpoint to a specific speed (I've heard 3/4 of max speed is usually pretty good). Then increase the kF until the actual speed matches the setpoint. From there, you can start to play with small values of P and I to get your controller more accurate.

This is better explained in section 12.4. Velocity Closed-Loop Walkthrough – Java, Talon SRX Software Reference Manual.

Maybe OP can start with just describing the problem symptom. An oscillating velocity-closed-loop-output when the target is fixed is a common problem, usually solved with proper gain tuning. Adding an F-term will help, allowing you to have a sharper P-gain with less overshoot.

@Ozrien, one of the students at the school would like to see me show up during this week so I might try to see if I can grab a few videos of the shooter specifically. Preferably when the shooter under-shoots, but I'm unaware of the entire situation. I'm aware that there has been shooter-related issues, I'm aware that we never tuned for an F-term, I'm also aware that the P term shoots up our overshoot to setpoint + offset where the offset is the height of the oscillation within the 5-10 seconds where the shooter is active. If I can, I may also try to record the data output from our encoder on the output shaft no real big deal if I cannot get all of the data that should be needed..