We’re pleased to announce the start of Open Alpha Testing for the 2024 version of Phoenix 6!
This alpha is compatible with the 2023 version of FRC software and WPILib.
See our blog post for more information and how to access the alpha:
Absolute W from the CTRE team
4 Likes
MCAP/foxglove support. Very cool.
3 Likes
This is such a neat set of changes.
Does the new swerve drivetrain object wrap the WPILib Odometry and Kinematics or is it a custom implementation?
1 Like
We wrap the WPILib classes and implement threading in our class to utilize the synchronous API.
Doing it this way allows us to achieve 250 Hz odometry/control frequencies on a CANivore bus.
You can peak at the implementation in our API Documentation.
10 Likes
16 Likes
I’m glad to see this transparency regarding upcoming features and an open alpha program to go along with it. I still remember the original launch of Phoenix after Kickoff in 2017!
My apologies to the person/team that worked on the differential control features only to have them ship out in a year where they lost their most notable use case.
4 Likes
Incredible updates from CTRE. Phoenix 6 has truly proven a blessing!
Love the updates to closed-loop control, it’s huge for teams who lack sufficient training to know the math and implementation behind more complex closed loop control.
2 Likes
There was just a post about that double elevator that was diffy controlled 
Is the swerve API eventually coming to more languages or will it remain exclusive to Java?
This seems really good. If only there were hardware to run it on…
In all seriousness, great work here. Lots of very substantial quality of life improvements, and the API is so much more readable now that it’s not so flat.
4 Likes
The best change.
1 Like
May none of us have to deal with acceleration in units of counts per decisecond per second ever again.
18 Likes
I cant wait to be able to deprecate my conversion methods.
4 Likes
What does CTRE think of a public roadmap for their software updates? It would have been great if I didn’t spend half of our meetings this summer making an equivalent software as to what CTRE just released.
8 Likes
Hi~ I just read the source code about the SwerveModule, and have a question about the m_couplingRatioDriveRotorToCANcoder in getPosition(), it looks like this
public SwerveModulePosition getPosition(boolean refresh) {
if (refresh) {
/* Refresh all signals */
m_drivePosition.refresh();
m_driveVelocity.refresh();
m_steerPosition.refresh();
m_steerVelocity.refresh();
}
/* Now latency-compensate our signals */
double drive_rot = BaseStatusSignal.getLatencyCompensatedValue(m_drivePosition, m_driveVelocity);
double angle_rot = BaseStatusSignal.getLatencyCompensatedValue(m_steerPosition, m_steerVelocity);
/*
* Back out the drive rotations based on angle rotations due to coupling between
* azimuth and steer
*/
drive_rot -= angle_rot * m_couplingRatioDriveRotorToCANcoder;
/* And push them into a SwerveModuleState object to return */
m_internalState.distanceMeters = drive_rot / m_driveRotationsPerMeter;
/* Angle is already in terms of steer rotations */
m_internalState.angle = Rotation2d.fromRotations(angle_rot);
return m_internalState;
}
what’s the point for
drive_rot -= angle_rot * m_couplingRatioDriveRotorToCANcoder;
Is this only for differential swerve module or for any kind of swerve module?
1 Like
For many of the popular swerve modules, when you steer around the module, the drive wheel also spins a little.
2 Likes