CTRE Phoenix Framework

Hello FRC Community,

As we are close to FRC Kickoff I’d like to update the community on what CTRE has been up to.
We just put up CTRE Phoenix Framework, our FRC library for supporting our various CAN devices.
If you plan on using a Talon SRX, Victor SPX, CANifier or Pigeon, you will need this install.
This is also necessary for installing the web-based configuration in the roboRIO, which is important for setting device IDs for PDP and PCM.

I’m sure this will bring up some questions, here are some answers.

  • Why is there a separate library?
    Historically the CTRE device classes were baked into the WPILIB and NI Kickoff release. This changed last year, which required us to learn how to best install the libraries for our motor controller and Pigeon IMU. Since it was the first year that we had to do this, we chose to make a simple installer and just distribute binaries to ensure successful use of our devices.

This year is “round 2” of the same effort, but this time with two new devices: Victor SPX and CANifier, combined with a growing list of customer-requested features that required back-breaking changes to firmware and API.

Additionally, it has become clear that the object model of our software would have to grow to accommodate a wider range of functionality. Concepts like gear ratios, sensor resolution, motor groups, etc. would have to be done in the API level. Sometimes you can’t just do everything in Talon firmware.

For these reasons, it seemed right to invest in a library that gave us room to grow while still providing basic drivers for our CAN peripherals.

-And after Kickoff?
Due to the amount of testing necessary for this initial release, we had to prioritize ensuring the base device classes work.
For that reason, the Servo/Gearbox/Drivetrain classes are not part of the kickoff release, and will be provided in a post-kickoff release.
This is also true for the Pigeon-Integration and remote-sensor features.
The full list is here….

-Why is the web-based configuration missing?
The default image on the 2018 roboRIO does not come with the web-based configuration. This can be installed using our software (LifeBoat), which is part of Phoenix. Instructions can be found here…

-Documentation / Examples?
This time we are trying something new with documentation. Personally, I love having PDFs with bookmarks, but the younger generation seems to favor a more open-source/collaborative style of communication. Thus, we’ve been moving our documentation into…

This is a top-to-bottom document to cover device use for all Phoenix supported CAN devices. A lot of the content has been reorganized based on feedback solicited from previous years.
This also includes a migration guide…
We will be updating these continuously to better support FRC teams.
Our examples are also being ported and moved to…

  • Talon SRX and Victor SPX do not support SpeedController? And why all the back-breaking changes?
    First…calm down…

I have had the most fun introducing and supporting the CAN Talon in FRC. Prior to Talon SRX, there hadn’t been anything quite like it in terms of functionality. And I’m excited to see how Victor SPX will be used this season.
After three seasons of development the CANTalon driver had become a hodgepodge of software.
It had several reverse functions, closed-looped settings that didn’t quite mesh with the open-loop features, two types of voltage compensation, and a ton of glue code to make it work in WPILIB’s object model. Function names sometimes confused customers as they were carry-overs from the CANJaguar days.

If we were going to continue to expand, we would have to make some fundamental changes.

This year introduces two core motor controller classes: TalonSRX and VictorSPX, which does not implement any of the WPILIB interfaces.
BUT we do provide a WPI_TalonSRX and WPI_VictorSPX that does. These are subclasses meant to provide the interfaces that WPILIB designed for. This includes support for WPILIB drivetrain classes.
We have also dropped the CANTalon moniker as most Talon SRX users use CAN and not PWM.
PWM classes are still provided by WPILIB, they are now called PWMTalonSRX and PWMVictorSPX.

For those that wish to combine the advance features of the Talon SRX/Victor SPX but continue to use the WPILIB objects which are primarily designed for simple motor controllers, feel free to copy/fork/subclass/extend the WPI_TalonSRX and WPI_VictorSPX. They exist for this exact purpose.

Our RobotBuilder plugins also uses WPI_TalonSRX and WPI_VictorSPX (Again you must install Phoenix).

-Anything broken in the Kickoff release?
As mentioned the new classes are not included in the kickoff release.
Additionally, the 3.1 firmware for Talon SRX and Victor SPX have motion profile temporarily disabled due to changes in the frame format. This will be addressed in an update soon. This has to do with the changes necessary to accommodate the new features.

If anyone has further questions/concerns, please contact our support or reach out via the GitHub repositories.

Change can be scary but sometimes it’s necessary to get to something even better.

Thank you for your patronage.
Thank you for the product feedback (good and bad).
Thank you for the opportunity to continue making cool robot parts.
As always we will do our best to meet your expectations.

Any chance we can get the libraries themselves released via maven? Many of our machines are not running Windows and this would make builds a lot simpler.

What’s the best thread title to use on CD for support? Does it help if I include a meme?

There’s also an incubating PR for maven support in phoenix rn, but it probably won’t be implemented in time for kickoff.

What does this mean for Python teams? Can we continue about our business already or will we have to upgrade to the latest firmware for 2018 and then have no API?

I would imagine you’d have to upgrade firmware to abide by the rules. I’m no RobotPy expert, but with all the stuff that’s been going on with pheonix I find it hard to imagine how it’ll be pulled off by kickoff.

Why do you say that? The minimum Talon SRX firmware hasn’t changed in the past. It was 1.01 in 2017, same as 2016 and 2015.

Of course it helps.

Is there an ETA for motion profile support being re-added? We rely on it quite a bit, and lengthy delays would greatly harm our autonomous development.

+1 on an answer to this

Does this we can stick with the current SRX firmware, but would need to upgrade if we wanted to use SPXs?

RobotPy is planning to create usable bindings for the TalonSRX, VictorSPX, Pigeon, and CANifier devices. With some luck, they’ll even be ready before the end of kickoff day.

I am not currently planning on developing any of the other stuff that comes with the Phoenix framework at kickoff. My expectation is that (a) the devices will be useful without the framework pieces, and (b) if the framework pieces are useful, community members will port them and make them available as the season progresses.

There seems to no longer be the ability to manually specify how long each point runs for in motion profile mode (used to be TrajectoryPoint.timeDurMs). How long does each point execute for?

There will be a function called configMotionProfileTrajectoryPeriod(ms). It had to be moved out of the trajectory point to make room for robot-heading.

In LabVIEW it’s already in the motion profile palette.

So if I understand this right, we’ll now have to set a single trajectory period for all points on a profile where we last year could set different times for each point? (eg shorter or longer as needed)


Omar, can we still set a trajectory point as “velocity only”? I don’t seem to find that option or a way to configure it like that in this year’s (Phoenix) library. Yet the Motion Profile Software Guide still references the older library.

Any pointers on how to set a motion profile based solely on a velocity trajectory point?

Is the Motion Profile a position-closed loop, velocity-closed loop or any other mode?



Are you using this one? https://github.com/CrossTheRoadElec/Phoenix-Documentation/blob/master/Talon%20SRX%20Motion%20Profile%20Reference%20Manual.pdf

Thanks Joe, that seems to be the updated version. I was using the one you download from the CTRE website.

Still, after reading the 2018 manual, I’m unclear as to how I can set a velocity-only trajectory point. Until I can test it, my guess would be to:

  1. Only set F gain in PID and leave all other parameters as zero (0).
  2. Insert a trajectory point with velocity data, and leave position and heading set to zero (0).

Is that correct?

Yeah, doesn’t matter what you put in the position and heading slots, just set your PID gains to zero, and leave your F gain the way it is. That way it won’t do any closed loop control, it will just follow the feedforward velocity points.