PIDController + Latency - related issues

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