Hello, I would greatly appreciate if someone would look at my code and tell me if I’m doing something wrong with the sysid routine. When I press the button to run the routine the swerve modules drive but it sounds like the gears are grinding.
You can’t create multiple TalonFX objects in code and control them, otherwise your control will stutter. You also should not create a duplicate Pigeon2 object. You can get the Pigeon2 Rotation3d using getRotation3d(), and you can get the Pigeon2 itself using getPigeon2().
We released Phoenix 6 24.2.0 yesterday which includes SysId swerve requests for translation, rotation, and the steer motors. You can use this to plumb the voltage to the swerve drivetrain using setControl(). As for logging, you should use the CTRE SignalLogger and extract the hoot files to wpilog using Tuner X. We have an example of setting up the SysIdRoutine with our logger here.
Didn’t creating multiple TalonFx objects with the same CAN ID used to throw an error? Is there a reason that wasn’t included in Phoenix 6 or was it an oversite?
I don’t think it did (or at least I don’t see any code that would do so, and I don’t see any warnings in simulation). In Phoenix 6, technically the only issue with creating multiple device instances with the same ID is control; everything else (status signals, configs, etc.) works fine.
We still recommend that you don’t create multiple instances anyways, as you get a separate set of StatusSignal instances with a new API device instance. That means that if you waitForUpdate on a StatusSignal on one instance, it won’t affect the StatusSignals on the other instances, which is not what you want with our swerve API.
We also made sure our swerve API exposes all the underlying devices so there’s no need to construct duplicate device instances. You can get the Pigeon2 directly from the SwerveDrivetrain, and you can get its yaw, synchronously updated with all the module positions, from the odometry pose. You also have access to each module’s motors from the apply() function of a SwerveRequest, which is the intended level of abstraction for something like implementing SysIdRoutine.