PigeonIMU sim doesn't work when connected to a TalonSRX

[sampdubs]

I am working on simulating my team's 2022 robot. I was having issues with simulating the Pigeon IMU, and after a lot of digging through source code and trial and error, I found that the simulation worked as expected if instead of constructing the WPI_PigeonIMU object using a Talon (which reflects how it is wired on the bot), if I instead constructed it with a device ID (meaning it would be wired to the CAN bus), simulation works as it should. I would expect simulation to work the same whether the IMU is connected through CAN or a Talon data port.

For reference, this code does not change the simulated IMU angle:

WPI_TalonSRX talon = new WPI_TalonSRX(1);
WPI_PigeonIMU pigeon = new WPI_PigeonIMU(talon);
pigeon.getSimCollection().setRawHeading(drivetrainSim.getHeading().getDegrees());

And this code does change the simulated angle, reflecting what would be expected given drivetrain inputs:

WPI_PigeonIMU pigeon = new WPI_PigeonIMU(2);
pigeon.getSimCollection().setRawHeading(drivetrainSim.getHeading().getDegrees());

[JCaporuscio]

After some digging it looks like there's a bug in Java where Pigeon's SimCollection does not get properly initialized for ribbon-cabled pigeons.

You can work around it by manually creating the Pigeon SimCollection:

  WPI_TalonSRX talon = new WPI_TalonSRX(0);
  WPI_PigeonIMU pigeon = new WPI_PigeonIMU(talon);
  BasePigeonSimCollection pigeonSim = new BasePigeonSimCollection(pigeon, true);
  pigeonSim.setRawHeading(drivetrainSim.getHeading().getDegrees());

Note that it looks like there's a separate issue that currently requires simulated ribbon-cable connected Pigeons to be used with a Talon of device ID 0.

[sampdubs]

Is there a fix for these problems? I can't find any reason looking through the source for the Talon to need to have ID 0. I assume this is something deeper to do with HAL or the JNI code?

[JCaporuscio]

There is currently no direct fix available - the issue lies with the Pigeon Simulation class that exposes access to the underlying simulation that's running.

The current options for workarounds are to either:

• Force the ribbon-cable pigeon to use a Talon of ID 0 during simulation (doesn't necessarily have to be a 'real' Talon)
  OR
• During simulation use the constructor for a direct CAN-connected Pigeon instead of the constructor used for your real ribbon-cable pigeon.

[sampdubs]

Ok, that's basically what I assumed. We can certainly implement one of those, but the current situation is unexpected behavior. Thanks for the quick help!

[JCaporuscio]

We have an internal fix for this now - the next official release may not be soon, so if you'd like to utilize the fix feel free to use our development build below.

Development Vendordep URL:
https://maven.ctr-electronics.com/development/com/ctre/phoenix/frcjson/5.21.1-13-gead2255/frcjson-5.21.1-13-gead2255.json

Keep in mind that because this is a development build it hasn't gone through our normal testing process, it's just a build of our latest internal Phoenix libraries.

[sampdubs]

Oh, that's great! We will wait until the next stable release, as the workaround works fine. Thanks for the update!