Strange gains when SysId tuning

For context: the drive motors (TalonFX) for our robot are on a canivore, so we’re using this modified SysId to run. Also, since we don’t have much space, I’ve been running the dynamic tests at only 2ish volts, which could potentially be too slow. I’ve run SysId multiple times and gotten similar results, so I don’t think it’s just an outlier bad run.

The only tuning test so far that I’ve done is set a goal velocity of 0.5 m/s, and the robot travels at 0.3 m/s, which isn’t great. The main thing that I thought was kind of strange was that when I decrease the velocity tolerance (which should make Kp increase? and has done so in the past), the calculated Kp value also decreases, and is very very close to 0. Is that expected?

I’ve included a SysId data file here. Below is the accompanying picture of what SysId looks like when it’s loaded in.
12_12_Swerve.json (746.5 KB)

Any help or information appreciated!

I believe the PD gains are low because it expects that most of the control effort is from the feedforward, whos gains are further up.


This is accurate. With a velocity controller its expected that the feedforward be responsible for the majority of the control effort. You can adjust the gains by tweaking the max control effort and max velocity error settings.

The dynamic voltage may be too low as well, but the data you’re getting back from the test seems decent, so I’m not sure about that.

Some further questions:
Where are you running the PID control? If you are using the falcon velocity control you’ll need to select that for “Gain preset”

Why is the measurement delay set to 83.734ms?

Can you try resetting to the default gain preset? I think I may have found a bug in SysID. Changing the measurement delay from the default 0 and then resetting it to 0 does not reset the output gains back to the original outputs. Looks like this bug has been fixed upstream.

1 Like

probably because the most-recent version automatically estimates measurement delay from the characterization data (it looks at time delay before peak acceleration is reached, under the assumption that inductive timescales are small and can be ignored compared to signal delay) :wink:

Your measurement delay is a bit more than half of your response timescale. This means your mechanism isn’t very controllable (you get about two whole iterations of meaningful feedback between adjusting your output in response to an error, and the mechanism reaching the new steady-state). SysId is shrinking your gains to keep the loop response stable; the bizarre backwards dependence on error tolerance is a result of this (it still doesn’t make perfect sense to me, perhaps @calcmogul can elaborate, but I have observed it in heavily-delayed systems as well).

Look into ways to reduce your measurement delay.

1 Like

Yeah, I figured that out- the canivore fork split after 2022.4.1 release that I was testing with.

1 Like

I don’t think I’ve understood measurement delay correctly. I thought it was characteristic to the robot/motor software, and thus there was nothing I could do to change it? What could I do to reduce my measurement delay or where could I look to find more info?

If possible, could you clarify what this means? Do you mean that the drivebase itself is physically hard to control, or that for some reason the program is getting problematically sparse feedback?

There are velocity filtering settings in the CTRE firmware that can be adjusted through their API. These are the major drivers of signal delay when running on-motor-controller loops with the internal Falcon encoder.

You can naively approximate the effect of sensor delay by imagining you’re actually running the loop at a lower update frequency. To understand this, think about what happens if the measured signal doesn’t change an appreciable amount within the span of a single iteration - in that case, multiple control loop iterations do effectively the same thing as a single control loop iteration.

Heuristically, we can just imagine a control loop running approximately once every n milliseconds, where n is the total signal delay in the chain. This is not an exact description of what’s going on, but it is a good approximation for understanding why the system is hard to control.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.