Phoenix Pro fused CANcoder w/ swerve (Help)

Hello all, I am currently shadow coding Phoenix Pro support in our team’s standard library and ran into the issue of unclear behavior regarding the use of a fused cancoder with the falcons integrated PID. As such I woud like to see if I can clear up a few questions I had about this. (This is all for swerve azimuth control btw)

  1. Does the falcon’s integrated PID use the cancoders absolute or relative position measurements? Because its used the relarive measurements with Phoenix v5 but we had the option to configure it to boot to absolute.

  2. If it uses the relative measurement, is there a way to configure the encoders boot behavior like in Phoenix 5? Or does it just have to be done through a set command on init.

  3. Non swerve related Phoenix Pro questions: is ther any way to access the pigeon 2’s compass reading (not just magnitometer), and do the fault bit fields for all devices still have the same layout as in phoenix 5 as i can find any documentation on this.

Thank you everyone in advance!

1 Like

Hi Roman!

The TalonFX uses the CANcoder’s reported position (as in the same value you get from getPosition()). In Pro, CANcoder always boots to absolute position. We make use of this in our Swerve Drive Example for the steer motors so they’re always absolute to the swerve module.

You’ll need to first magnetometer-calibrate the Pigeon2 to enable the compass, but I’d strongly recommend against using the compass in any context with electric motors and large metal frames. The changing magnetic fields that are present around FRC robots make compass more of a detriment in practical use from our testing. You’ll likely have far better luck with the accel-gyro from the Pigeon2 by itself.

The fault fields in Pro changed to be single fields. An example of this is the getFault_BootDuringEnable() method.
More information is available in our migration guide:

Hope this helps!


Thank you very much for your response! I had no idea that there was a swerve drive example and that will surely help a lot. Additionally, on the subject of the pigeon, while I understand it is not nesisaraly recommend, i was just wondering if there was a way to still access thoae valuae throuf the api to ensure compatability with our internal 3-axis magnitometer/digital compass interface. Finaly, regardig the statuse signals,do you know of any resources where i can find a layout of which bit in the phoenix pro fault field integers corresponds to which fault for each device. While this may seem like an odd request, our internal self-test system relies on bit field based fault lists to function. Previously we used the Phoenix 5 Fault classes to identify this order for each device.