PIDController + Latency - related issues

Technical Programming
1

I tried to correct the name of this post as well as clarify, but I noticed it was removed from more than one place so I have just deleted and made a new post in hopes that I can make more sense this time otherwise I’m not going to bother with this theory I’ll just simulate what I’m thinking then post the simulation link here later. On to my thoughts:

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. Upon seeing tests between teams and competition matches where teams have had issues with shooting into the high goal. Here’s the programming side:

Everything has a delay, hopefully in milliseconds, but that’s typically known as “latency” and happens to be the reason why gamers tend to use keyboard + mouse over an Xbox controller.

Latency baselines: Xbox 360 Controller: 66ms Xbox One Controller: 33ms RoboRIO: update period -> 20ms Network latency: <5ms (it varies) Driver Station software latency: depends on CPU, anything made after 2013 has at least a baseline of <15ms to capture the Xbox Controller and send it back via network tables to the roborio. Celeron/Pentium CPUs: <15ms, i3 (3rd gen or later) or AMD equivalent: <11ms, i5 (4th gen or later) or AMD equivalent: <10ms, i7 (4th gen or later) or AMD equivalent: <9ms.

Making all of this into a calculation, Xbox Controller + RoboRIO + network latency + DS (+ encoder latency, which we will say it manages to acquire the data instanuously) = overallLatency

In this case we’ll be measuring with an Xbox 360 controller: 66 + 20 + 5 + 15 = 106ms = 0.106 seconds.

On with the Xbox One Controller: 33 + 20 + 5 + 15 = 73ms = 0.073 seconds

Despite the Xbox One controller being noticeably faster (during calculation), the latency on the Xbox 360 Controller is roughly 212ms to receive as well as send a packet to/from the controller where the Xbox one controller is 146ms. Let’s look at this latency as part of the PID; start by giving a setpoint of 4600/6000 (rpm) = ~76.7% motor speed. Here’s what the PIDController looks like while attached to a motor: http://www.globalspec.com/ImageRepository/LearnMore/20127/Derivative%20Controlf33d02a7a8b14c83bea54ae58d67cc19.png

The next step in this process is to find out the length of time it takes for this given data. I don’t really have a lot of access to this type of information right this second, but I certainly can update the post when I figure out how to handle the data correctly in a simulation or I can get feedback from team(s).

Either way, the latency plus the speed of the motor are highly likely to cause issues while shooting unless you compensate on the roborio for that. Using a PID-based system where the shooter uses PID to control the mechanism that applies the most acceleration could cause issues with the speed of the ball being shot is actually under powered if designed ‘properly’.

For reference, I found his link from awhile ago to assist my point that PID never seems very consistent: http://www.chiefdelphi.com/forums/showthread.php?t=114366

While I’m certainly noting that it shouldn’t be “more word versus yours and therefore it weighs more”, teams should be aware of this consistency issue which was introduce back in 2013. Bang-bang is certainly an overly simplistic matter of a PID, but there also hasn’t been a lot of talk on the subject since. Consider this post a “let’s get to theorizing” thread. At the very least, we might help some teams who are falling behind right now due to missed shots or latency extensions.

CERTAINLY SHOULD BE NOTED: the PIDController and latency are two separate things ENTIRELY, but they are related depending on your control system setup. If anybody has a way to simulate the PID system.

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.

2

I’m very confused on what an xbox controller and network latency has to do with any of this. Usually the only thing people do with the controllers is enable the PID loop. The PIDController class runs entirely on the RoboRIO every 20 milliseconds in its own thread, however the encoders read much faster then that from the FPGA. Network latency has nothing to do with this, unless you are running the PID calculations on the DS laptop, which is HIGHLY unlikely, and definitely wouldn’t work.

3

You could probably handle the calculations on the DriverStation, agreeably you shouldn’t really attempt that. I have a feeling that the latency between when the PID gets to the setpoint and the ‘notifier’ goes off for your team either the roborio handles that and shoots or there is a person that has to shoot. If there is a person who has to give interaction for the shooter to ‘shoot’ then it could cause issues, correct?

4

It shouldn’t. The PID loop should have a consistent setpoint set, and if tuned right it will oscillate a little bit but will then converge on 0. If the drivers are telling the bot to shoot while the system is still oscillating, thats not a latency issue, thats a tuning issue. Tuning a PID loop, especially in a game like this, is HARD, and takes a lot of knowledge and time to get it working. Usually what teams do is set a tolerance allowed for the PID to be considered within range, and then shoot only if the shooter is within that range.

5

Agreeably, but some teams still tend to leave out the shootable range. Ideally, that would be the way to go - forcing the shooter to be +/- some lee-way (in this case) upon shooting. It just seems weird that some teams are still having issues with shooting if they’re using a PID and seemingly it could be setup ‘correctly’. Wouldn’t a bang-bang still be more reliable?

6

You seem to be operating under the assumption that a stable, 0 deviation from setpoint velocity is the only component to a consistent shot. This is far from the case. There are many mechanical factors that go into shot consistency that are unrelated to wheel velocity.

How so? A properly tuned velocity PID will usually provide better stability with similar (but definitely slower) setpoint adjustment speed. The bang-bang algorithm is simpler and requires very little tuning but will oscillate around the setpoint.

7

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.

8

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.

9

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.

10

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.

11

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.

12

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.

13

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.

14

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.

15

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

16

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!

17

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.

18

@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…