CTRE Pigeon PID issues

Hello Chief Delphi,

Question about using the CTRE Pigeon.

The optimal way to use a PID with the Talon SRX is probably using CTRE’s homebrewed PID. We forked and cloned their example code, and we are having some issues understanding and integrating the code.

https://github.com/CrossTheRoadElec/Phoenix-Examples-Languages/tree/master/Java

Particularily the use of timeouts. How do the inbuilt Periodic, well, periods relate to these timeouts, and the periods defined in functions like:

_rightMaster.setStatusFramePeriod(StatusFrameEnhanced.Status_14_Turn_PIDF1, 20, Constants.kTimeoutMs);

We modified this code to try it out, yes pretty jerry-rigged and not an amazing benchmark, but when we toggle the gyro assist, the robot stops entirely and no longer will move forward, or any direction for that matter.

This is a direct link to our Robot.java:
https://github.com/TrinityTrihawks/POCofCTREPID/blob/master/src/org/usfirst/frc/team4215/robot/Robot.java

We added two new motor controllers as slaves. Having never used the Master/Slave concept, however, we weren’t exactly sure how to properly do it.

Thank you for any insight you can give!

The CTRE Talon Software Manual explains the CAN frames better than I ever could. On page 132 of their Software Manual, you can see that the status frame is normally updated every 10ms. The first parameter of the method defines which status frame to change the refresh rate. The second parameter is the number of milliseconds for the new update interval. The last parameter just sets the new timeout of the frame to the API-wide default timeout.

As a whole, though, the line should intentionally limit the Talon’s secondary PIDF loop (turning) to update at half its traditional speed. I’m not exactly sure why they code this but I’d assume it’s so the primary loop reacts at twice the speed of the secondary loop. I’d guess that if you specify a specific value to update slower than the frame update rate, CTRE’s software holds onto the old value until it reaches the specified time (but this is just a guess).

As for your code, I don’t believe you need to explicitly change the feedback rate of your talons or pigeon, unless to be faster, as the defaults (mostly 10ms) will work fine with only 5 CAN nodes.

Any time they mention a timeout in their code, it’s talking about the timeout for the command to the Talon. So for example, if the Talon fails to receive that command the first time, the RoboRIO will keep on sending for up to the timeout period until it sticks.
The slaving thing is pretty easy as long as you don’t think too hard. Just set one Talon to follow another and it’ll do it until you tell it to do something else.
The status frames for feedback are great for graphing outputs and things like that. Just watch the CAN utilization on Driver Station and make sure it’s not going far over 80% or so.