Phoenix 6 setUpdateFrequency glitch on P and D

We have upgraded to Phoenix 6, and were hoping to use some AdvantageScope fu to start tuning our drive constants on our swerve chassis, but we’re stumped by our inability to get sufficiently fast updates for the proportional and differential components.

We have some code to throw those values onto network tables; code is here:
Automatons-2024/src/main/java/frc/robot/SwerveModule.java at 75fa778e5279a65be18addc97492850f8d8081ad · HP-Robotics/Automatons-2024 · GitHub

However, it seems as though despite all of our efforts, we cannot get the Proportional and Derivative output values to update more frequently than 250 ms.

You can see our current attempts at code to change that here:
Automatons-2024/src/main/java/frc/robot/SwerveModule.java at 75fa778e5279a65be18addc97492850f8d8081ad · HP-Robotics/Automatons-2024 · GitHub

We find that we can change the Integrated and Feedforward frequency all day long and it works fine. If we call optimizebus, then the P and D terms vanish completely, which sure seems like it correlates with the library thinking that we’re not using them.

The programmers spent 3 hours trying a lot of different variations with no luck. We also tried to get the error and compute the P component ourselves, but getClosedLoopError() also has the issue.

We even purchased the Pro license to get the full signals, and the full hoot file only has P and D at 250 ms intervals (with I and F nicely at 50 ms).

A wpilog and hoot log file can be found here:
Share log files - Google Drive
In the wpilog, you can see the behavior of any of the drive motors; e.g. drive-train/BL driving kP proportion vs the kF proportion. You see lots of updates for kF, but only every 250ms for kP.

I don’t have Windows at home, so I can’t load the hoot file, but any of the Falcons with an ID that is 2X where X is even should be a driving motor, and we observed the same behavior there.

Clue bats welcome.

Answering my own post. I emailed CTRE and got a very swift reply from them, indicating that they could reproduce the problem.

The most obvious work around was to use a CANivore, which worked fine for us.

Omar Zrien of CTRE also gave us an untested code work around that he thought might work on the regular CAN bus.

I will include it below, but it remains untested:

I wrote up a quick Java workaround. Add this extended class to your code and instantiate this class instead. Then you should be able to use the routine I added: setUpdateFrequencyPIDSignals
This is untested but is simple enough to where it should directly access the signal groups. I might have time at the end of today to formally test it.

class TalonFX_PID extends TalonFX {

public TalonFX_PID(int deviceId, String canbus) {
    super(deviceId, canbus);
}

public void setUpdateFrequencyPIDSignals(double frequencyFreq)
{
    /* comment out signal groups you don't care for.
     * Specify whatever 'frequencyFreq' you want for each group.
     * Each group can have a unique frequency if desired.
     * Be careful to not saturate the can bus when using RIO since it is not CANFD.
     * Do not change the other parameter inputs, regardless of which closed loop mode you intend to use. */
    super.lookupStatusSignal(SpnValue.PRO_PIDRefPIDErr_PIDErr_Position.value, Double.class, "err and ref", false).setUpdateFrequency(frequencyFreq);
    super.lookupStatusSignal(SpnValue.PRO_PIDRefSlopeECUTime_ReferenceSlope_Position.value, Double.class, "ref slope", false).setUpdateFrequency(frequencyFreq);
    super.lookupStatusSignal(SpnValue.PRO_PIDOutput_DerivativeOutput_V.value, Double.class, "dout,pout,out", false).setUpdateFrequency(frequencyFreq);
    super.lookupStatusSignal(SpnValue.PRO_PIDStateEnables_FeedForward_V.value, Double.class, "ff,iaccum", false).setUpdateFrequency(frequencyFreq);
}

}

1 Like

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