Hi Lavi~ thanks for the reply! Well I know the drive wheel will spin a little when the module rotate, but in this way it should be like
drive_rot -= (currant_angle_rot - last_angle_rot) * m_couplingRatioDriveRotorToCANcoder;
Or is there anything wrong about my understanding? 
I think the important thing to note here is that drive_rot is the total accumulated position of the wheel without any coupling ratio compensation. If drive_rot was the compensated value from the previous iteration, then your sample code would work.
Is there any plan to update the alpha for Phoenix 6 to build against wpilib’s 2024 beta?
Yep!
We do beta releases of Phoenix each year, usually starting within a couple working days of WPILib’s release. I expect we’ll have the initial release up early this coming week.
Keep in mind that vendor libraries have a dependency on WPILib. So even for vendors that closely follow WPILib’s changes there’s still time required after their initial release to make any final build changes and validate the vendor lib release before publishing it. Patience is appreciated while we get our software ready for y’all, we’re just as eager to have it available for you 
Thanks for the information. I didn’t mean to sound like I was clamoring in my chair waiting for a release! Haha.
I appreciate all the work you put into Phoenix 6
Happy to report our beta libraries are now available!
Our testing took a bit longer than anticipated as we discovered/documented some underlying beta software issues, but the WPILib folks were super responsive as always and are digging in to them.
I encourage anyone who’s working with robot software this off-season to check out the beta! More people who are testing and providing feedback means better software that NI, WPILib, and the Vendor teams can provide for the season.
Point of clarification - the beta libraries are building successfully in WPI 2023 for us, is that intended behavior?
The Beta release is simultaneously linked from the WPI 2024 page, which explicitly disclaims backwards compatibility.
Versions of WPILib prior to this 2024 beta don’t explicitly check the year of vendor dependencies, so there’s nothing to prevent the project from attempting to build.
It’s entirely possible that some or all of a vendor library will successfully build with a prior year; particularly in Java if the API hasn’t changed (the compatibility issues are more likely to be in the underlying C++ binaries).
BUT there’s no guarantee that it will fully work - you may run into crashes or unexpected behavior on deploy or while running the robot project.
This is why WPILib goes out of their way to say vendordeps aren’t compatible across years and has (with 2024) put explicit checks in to prevent even loading vendordeps for the wrong year.
TLDR:
Is it intended? No
Is it possible? Yes… but don’t rely on that.
As far as compatibility, as soon as we update to phoenix 6 firmware does it break anything using 5?
Want to start testing on hardware but dont want to lose the ability to run our 2023 codebase
We’ve been using the Alpha firmware of Phoenix 6 on our off-season code projects and I’ve generally been a fan. The new serve template code works exceptionally well out of the box….Like drop in our PathPlanner command function with small tuning and consistently hit 3 piece autos level nice.
Must sync with the pidgeon or something too to be that accurate
Phoenix 6 firmware will only work with the Phoenix 6 API, but you can switch back to the Phoenix 5 firmware at any time.
Phoenix 6-flashed devices will also work on the same bus with Phoenix 5 devices without issue. Plus Phoenix 6 and 5 can both be used in the same robot project.
ah cool! Guess I can’t be lazy and have to swap FW back.
Good to know! Thanks!
Where does the swerve api actually run? I haven’t traced through the source I can see but thats still in the software layer correct?
I am curious why the swerve example has ignoringDisabled(true)
drivetrain.setDefaultCommand( // Drivetrain will execute this command periodically
drivetrain.applyRequest(() -> drive.withVelocityX(-joystick.getLeftY() * MaxSpeed) // Drive forward with
// negative Y (forward)
.withVelocityY(-joystick.getLeftX() * MaxSpeed) // Drive left with negative X (left)
.withRotationalRate(-joystick.getRightX() * MaxAngularRate) // Drive counterclockwise with negative X (left)
).ignoringDisable(true));
We have ignoringDisabled(true); mostly so changing the request behaves as expected. If ignoringDisabled(); is set to false, the command won’t run periodically while the robot is disabled, and there may be confusion switching out the request for one that could run while disabled.
An example of such a request would be a hypothetical music request, where the FXs in a swerve drive emit a tone or play a chrp file, which is now possible while the robot is disabled in Phoenix 6. The motors still behave safely since the robot disable prevents them from driving, and having this flexibility is useful.
I updated the rio, tuner, and everything I need, but get this error in driver station when attempting to deploy a temporary diagnostic server: /home/lvuser/PhoenixDiagnosticsProgram: error while loading shared libraries: libFRC_NetworkCommunication.so.23: cannot open shared object file: No such file or directory
Figured out that WPIlib 2024 installation failed, that was the solution I believe.
CTRE does not currently have a 2024 beta Tuner released, so deploying the temporary diagnostic server will not work on a 2024 imaged roboRIO. You can deploy an empty robot program with a CTRE object initialized (ie, create a TalonFX or other device in the robot program) to work around this. Tuner will then be able to connect like normal.
Failed how? Was there any error message you received, or another indication that this was the case?
With the retirement of the WPILIB sysid characterization tool I was wondering if you had plans to add swerve characterization commands for your swerve architecture. Something that would use your data logging and go through the motions and log what the sysid data analysis tool wants so that we could have clean feed forwards and PID values. Preferably written in C++ to avoid any data noise due to Java garbage collection pauses
Edit
It could even be an entirely different project to avoid conflicting or cluttering the robot competition code. That way the autos that need ran could be loaded into a dashboard and everything.
I realize this feature request is more work but to be able to du that within phoenix tuner x and get the PID (steer position and velocity) and FF values for the drivetrain would be incredibly useful.
I just realized that the new default update rate for the closed loop controls is set to 100hz. As far as I remember it was advertised as 1000hz on v5.
/**
* The period at which this control will update at.
* This is designated in Hertz, with a minimum of 20 Hz
* (every 50 ms) and a maximum of 1000 Hz (every 1 ms).
* <p>
* If this field is set to 0 Hz, the control request will
* be sent immediately as a one-shot frame. This may be useful
* for advanced applications that require outputs to be
* synchronized with data acquisition. In this case, we
* recommend not exceeding 50 ms between control calls.
*/
public double UpdateFreqHz = 100; // Default to 100Hz
Is there a specific reason behind this change and or is it suitable to change it to 1000hz for all control modes?
I’m not sure whether this is CAN stuff or onboard PID controller stuff