PIDController + Latency - related issues

[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.