[CTRE] 2024 Phoenix Software Now Available!

Technical Programming
,
1

It’s that time of year again! The CTRE Phoenix Software packages are now available for the 2024 season. Links are available at the bottom of this post.

The road to get here started in the early off-season and was made possible by the invaluable contributions of alpha and beta testers. Across a total of 16 pre-season releases (8 alpha releases and 8 beta releases) you’ve updated, simulated, generated, closed-looped, and chrp’d your way through testing some of the largest feature additions and changes we’ve ever released. We’d like to give a resounding Thank You! to everyone who’s tested and contributed feedback for Phoenix this year, including all of our test teams, community members, and WPILib developers who helped make this year’s release what it is.

We’ve captured the major changes and most important reminders below, but there’s too much to fit in one blog! For a full list of changes check out our “New for 2024” page here:

New for 2024

Changes to Phoenix Components

Phoenix 6

New for 2024 is the Phoenix 6 library (formerly known as Phoenix Pro). You can find more details and our previous announcement here, with the major points as follows:

  • Phoenix 6 is the new version of the Phoenix library and is free for all users
  • Phoenix 6 supports Talon FX (including for Kraken X60), CANcoder, and Pigeon 2.0.
  • Phoenix 6 and v5 can both be used in the same robot project - simply add both the “Phoenix 6” and “Phoenix 5” vendor dependencies.
  • Phoenix 5 is not going away and will be supported for the foreseeable future. However, the TalonFX, CANcoder, and Pigeon2 classes in v5 are deprecated (but still present!) for 2024 and will be removed in 2025. We recommend using v6 for these devices instead.
  • Phoenix 5 does not support the Kraken X60’s Talon FX.

Note: Phoenix 6 is currently available for all FRC languages except LabVIEW. There is a Phoenix 6 LabVIEW alpha being developed for teams who are interested in using Phoenix 6 features in LabVIEW. Teams who are interested in this may reach out to us directly.

Phoenix 5 LabVIEW VIs are available now in the kickoff release.

A migration guide is available here to help you port your Phoenix 5 code to Phoenix 6.

Phoenix Pro

Since Phoenix 6 is freely available, Phoenix Pro no longer requires a separate API. Instead some advanced device features in Phoenix 6 require a Phoenix Pro license. We also have a new licensing type available for 2024 - the Phoenix Pro Season Pass.

You can see which features require Pro here:

Phoenix 6 Features

An overview on Season Pass is available here:

Phoenix Pro Licensing: Announcing Season Pass - CTR Electronics

And a breakdown of the different license types is available here:

Phoenix Pro

Phoenix Tuner X

Phoenix Tuner continues to evolve, and Phoenix Tuner X has a full set of new features and improvements to take advantage of, including batch device licensing, plotter improvements, and a swerve robot project generator.

IMPORTANT Note: On computers that already have Tuner X, make sure you have the latest version installed by comparing the version in the upper-left title bar to the latest version listed in the links below. If you need to update, go to Tuner X’s Microsoft Store Page where there will be an “Update” button.

Major Features

API Improvement

Phoenix 6 is a significant API improvement over Phoenix 5 and has been designed to integrate cleanly with modern programming practices and WPILib.

See the documentation on Phoenix 6 API usage for full details.

Swerve Support

Phoenix 6 has a new API to make programming swerve easier than ever. Tuner X also has a swerve project generator that will create a custom base robot project in Java to get your swerve drive up and running fast with CTRE devices.

The base generated project works with a gamepad out-of-the-box and can also easily be used with Pathplanner!

Data Logging

Phoenix 6 features a real-time, high-fidelity signal logger that captures every CTRE device data point as it is received from the CAN bus to a .hoot log file. Signal logging is enabled by default during official matches and can be enabled by an API call for all other cases (including simulation and hardware-attached simulation).

Using the Tuner X log extractor, all users can export common data signals to standard WPILOG format, and Pro users can export a full set of advanced data signals to both WPILOG and MCAP formats.

As a bonus, thanks to work done by the AdvantageScope developers you can import a Phoenix .hoot log file directly into AdvantageScope!

SysId Characterization

Our engineers worked with the SysId development team to provide real-world test data and ensure a smooth experience in characterizing mechanisms. All v6 users can utilize the data logged by Phoenix to get an extremely accurate mechanism characterization from SysId by exporting the data to a WPILOG!

Automatic timestamps of Phoenix logged data also means you can get accurate characterization regardless of which programming language is used.

New Motion Magic® Controls

Phoenix 6 has several new Motion Magic® features. This includes Dynamic Motion Magic® (requires Pro and CANivore) to allow adjusting trajectory constraints during motion, Motion Magic® Velocity to run a velocity motion profile, and Motion Magic® Expo to run an exponential profile using system characteristics.

… And More!

There’s too many new additions to link in one blog post, so be sure to read our “New for 2024” documentation!

2024 Phoenix Links

Software Downloads, Documentation, API reference, and Examples can all be found on the main CTRE Phoenix page:

https://docs.ctr-electronics.com/

The latest versions available are:

  • Phoenix 6: v24.1.0
  • Phoenix 5: v5.33.0
  • Phoenix Tuner X: 2024.6.1.0
  • Phoenix Offline Installer for FRC: v24.1.0.0
32 Likes
2

2 questions:

Say a TalonFX is being used for a flywheel and is just using the RotorSensor as the FeedbackSensorSourceValue. If the flywheel has a gear ratio of 2:1, a user would then configure the SensorToMechanismRatio to 2 in the FeedbackConfigs configuration.

Do all values in the Slot configs obey the SensorToMechanismRatio? Say for example, a user has configured a kP to be 4.8 V / RotPerSec. Is that error calculated from the rotor error before or after the SensorToMechanismRatio value?

Furthermore, when setting the velocity, acceleration, and jerk, can we pass in mechanism speeds or does it have to be converted to rotor speeds?

Second question is about the Phoenix 5 function SetSelectedSensorPosition. How can we reset the rotor sensor to be 0 in Phoenix 6? My first assumption would’ve been to set FeedbackRotorOffset to the current rotor position in FeedbackConfigs configuration, but the docs say that won’t work for anything outside of one rotor rotations. Therefore what would the recommended way be for setting a multi-rotor rotation to 0?

3

The PID/FF gains and Motion Magic® configs operate on the Talon FX position, not rotor position, so the error is calculated after the RotorToSensorRatio and SensorToMechanismRatio.

The equivalent to SetSelectedSensorPosition in Phoenix 6 is SetPosition.

The FeedbackRotorOffset, similar to the Phoenix 5 configIntegratedSensorOffset, is an offset applied to the (absolute) rotor position of the Talon FX (since the Talon FX boots to its absolute position), which means the offset persists across power cycles. On the other hand, SetPosition sets the relative position to the specified value.

1 Like
4

Is the original pigeon no longer supported? I only see the pigeon2 in the docs. Unless I’m missing something?

5

Devices supported in Phoenix 6 are documented here: Phoenix 6 Requirements.
All other devices, including Talon SRX, Victor SPX, and Pigeon 1, are still supported in Phoenix 5.

1 Like
6

Swerve support is a welcome addition!

But will Talon SRX, Victor SPX, and Pigeon 1 still be supported next season when you phase out Phoenix v5 for TalonFX, CANcoder, and Pigeon2?

Why doesn’t Kraken support v5 this season since it is Talon-FX based?

It’s not ideal to have to use two sets of APIS for devices from the same vendor…

1 Like
7

Props to CTRE for being communicative and helpful during the last-minute scramble to keep SysId from lapsing this build season. Far and away the best interaction with vendor engineers I can remember since I got involved in WPILib. Without physical testing and data from @Daltz3, there’s no way the SysId work would have been done in time.

10 Likes
8

What’s the story on the firmware side?

It’s a bit difficult to figure out what is what in Phoenix-Releases/ctr-device-firmware at master · CrossTheRoadElec/Phoenix-Releases (github.com) at this point.

Are we going to get 2024 firmware for Talon SRX and Victor SPX or do we keep using 2023 firmware?

Is “TalonFX-Application-22.2.0.0-Season2024.crf” for TalonFX v5?

Is “TalonFX-24.1.0.0-Phoenix6.crf” for TalonFX v6?

What is “TalonFX-vC-24.1.0.0-Phoenix6.crf” for?

A compatibility table would be useful.

Thanks!

9

You shouldn’t have to worry about firmware directly, Tuner X will automatically select the latest and correct firmware for you for v6 or v5.

10

Thanks. How will Tuner X know if we want to use v5 or v6?

And is the old Tuner no longer supported?

11

Awesome additions all around - can’t wait to program with this! One question - is configFeedbackCoefficient for the CANCoder depreciated in v6? Or is there an alternative? Our team has found this extremely useful in the past, and were looking forward to using this again this year for our shooter mechanism.

12

Yes, they will still be supported in Phoenix 5.

The Kraken X60 requires a different firmware file (Talon FX vers. C). Since Phoenix 5 is deprecated anyways, we decided not to invest our time and resources into back-porting the Talon FX vers. C firmware to Phoenix 5.

Tuner X defaults to the firmware version currently flashed on the device. There is a toggle above the firmware dropdown that selects v5 and v6, as well as one that selects firmware year.

Tuner v1 is essentially in maintenance mode and will not receive any new features. This means that when used with Phoenix 6, Tuner v1 cannot do much more than set name/ID and field upgrade. Self Test, plotter, log extraction, control, swerve project generator, etc. all require Tuner X.

Yes, because CANcoder is now always in canonical units of rotations along with the rest of the Phoenix 6 API. We decided not to support runtime units in Phoenix 6 because we preferred to use the C++ units API (and potentially the Java units API in the future).

If you want to use CANcoder as a remote sensor, you can use the Talon FX RotorToSensorRatio to specify the gear ratio between the CANcoder and the Talon FX, and the SensorToMechanism ratio to specify the gear ratio between the mechanism and the CANcoder (typically 1.0).

2 Likes
13

I found the pigeon2 in the supported devices list but I cant find anywhere how can I import it, because the import “import com.ctre.phoenix.sensors.Pigeon2;” doesnt work anymore… at least it wont work anymore. Can you help me?

1 Like
14

The API reference is very useful, this is probably the class you’re looking for:

15

found it!! thank u very much

1 Like
16

hey dan, sorry to bother you again but do u know if theres a new function to replace the “.configMountPose”? I cant define the directions and stuff like that.

17

No worries. We don’t use the Pigeon but looks like MountPoseConfigs is the replacement.

I suggest you read the migration guide and in general the whole documentation (it’s not that long). It will help you get up to speed with the new version and features.

4 Likes
18

I am not able to install Phoenix 6 from the Releases page on github.

The offline installation does not work. How can I resolve this issue?

19

I am assuming this Phoenix v5 code:

cancoder.setStatusFramePeriod(CANCoderStatusFrame.SensorData, 10);
cancoder.setStatusFramePeriod(CANCoderStatusFrame.VbatAndFaults, 10);

is equivalent to (please correct me if I’m wrong):

cancoder.getPosition().setUpdateFrequency(hz);
cancoder.getFault_Undervoltage().setUpdateFrequency(hz);
20

Correct, although you’ll also need to do cancoder.getSupplyVoltage().setUpdateFrequency(100) if you want to speed up supply voltage (formerly Vbat).

If you’re setting multiple signals to the same update frequency, you can also do:

BaseStatusSignal.setUpdateFrequencyForAll(100, cancoder.getPosition(), cancoder.getFault_Undervoltage(), cancoder.getSupplyVoltage());

We also now support setting the update frequency to 0 Hz to completely disable frames, and a function to optimize bus utilization.

2 Likes