[CTRE] Phoenix Pro to Phoenix 6: Looking Back, and Looking Ahead

Technical
, , , ,
1

Software is an integral part of what we do here at CTR Electronics. Our goal is to always be pushing forward the software capabilities of the FRC community while making them more accessible to all teams.

For the 2023 FRC season we introduced Phoenix Pro: a new comprehensive API, firmware, and software tool collection for our latest CAN FD products. Our goal of introducing Phoenix Pro with a paid licensing model was to enable development of larger features and improvements that wouldn’t have been possible otherwise.

We also knew that in some ways Phoenix Pro would be a bit of an experiment. Paid software is new to FRC, so despite extensive preparation there would likely be growing pains or changes that needed to be made for future seasons. In addition the Phoenix Pro API is very different from the Phoenix 5 API due to the nature of the API improvements.

Starting with our early beta releases we’ve sought to collect as much feedback as possible in a variety of ways, including:

  • Phoenix Pro Beta Testers
  • Initial Community Response
  • Technical Support Requests throughout the season
  • Discussions with teams during build and at events
  • Ongoing discussion by the community on Chief Delphi and Discord
  • FRC Championship Event feedback
  • Active Post-Season feedback requests

Based on this feedback we have a major change to announce for Phoenix Pro:

Starting today, the Phoenix Pro API is becoming the free-to-use Phoenix 6 API!

The initial release of the Phoenix 6 API is currently available - see our full announcement page at the link below or see our latest software documentation for instructions.
Please note that Phoenix Pro firmware features will still require a paid Phoenix Pro license for use with Phoenix 6.

We’re excited for even more folks to get access to our best library yet and look forward to what teams can accomplish for the 2024 season!

For more information about what led to this change, how to access and use Phoenix 6, and details on which features will be exclusive to Phoenix Pro, see our full information page here:

Full Phoenix 6 Announcement Details

67 Likes
2

This is a good step forward from the initial rollout of Phoenix Pro. I hope bringing FOC into the free tier will be considered next.

15 Likes
3

Honestly, I was shocked there were API changes between the paid and free tiers. Seemed like extra friction to turn someone into a subscriber. Glad that’s fixed, this is definitely a better experience for teams.

19 Likes
4

Very cool! Loved chatting with CTRE folks at champs and glad they were open to team feedback.

Looking forward to using this over the off-season!

@dh28567 @Cheekibreekiski @Molly_Connolly

Question - will pricing for pro features such as FOC be posted/updated? Will we still be able to purchase the upgrade for all devices on a canivore?

3 Likes
5

Great change. The drastically changed API–even though it deviates from the “traditional” WPILib motor control API–is a very welcome improvement.

6

As of right now there aren’t changes planned for the Pro pricing.
Both individual device and CANivore whole-bus licenses will still be available.

We’re still looking at what, if any, improvements we can make to Pro licensing for next season. Any changes will be announced later this summer when 2024 licenses become available for purchase.

1 Like
7

Now everybody beeping!

4 Likes
8

The same API for both pro and non pro devices is a welcome change. While no company is perfect CTRE does a wonderful job of listening to customer feedback.

Calling brushed motor controller classes legacy classes seems premature. There are plenty of applications where a Falcon is overkill and an SPX or SRX with smaller motors makes sense and is more economical. I’d really like to see the api changes extend to the TalonSRX and VictorSpX.

10 Likes
9

Though a lot of the changes don’t apply to brushed motors this would still be nice.

3 Likes
10

Very exciting changes! Glad we decided to jump straight to learning pro in the off season.

1 Like
11

Okay, so if i understand correctly, the same classes in the phoenix 6 API will be used gor both Phoenix Pro and non pro licenced devices? If so, what happens if the user attmets to use a feature such as FOC that is unavailable without pro Firmware? Does the code crash or control request fail with a StatusCode? Or does it simply fallback to using a similar but supported version of the request (i.e. trapezoidal control instead of FOC). Furthermore, is there a way in code to determine what the licensing state of a given device is from code so as to determine what features are supported? While I understand the individual user is likely to be aware of what license they are running, I am asking these questions from the perspective of someone who has to maintain a library that is heavily dependent on bolth pheonix 5 and pro, and therfore the same general classes will have to work for both pro and stadard licenses, eventhough I still want to take advantage of pro features in supported devices. However, regardless of these questions, I am very excited for Phoenix 6 and the features it will offer!

1 Like
12

Thanks for listening to the community feedback. This is a welcome change.

8 Likes
13

Is there a reason for not moving talon SRX and Victor SPX controllers over to the new API or is it just they’re falling out of use and therefore not worth the effort and money to port them.

1 Like
14

Having thought about it more it is likely because they don’t support CAN FD so won’t work on CANivore bus.

15

Hm I could see that as being a reason but a lot of things like the units and signal API would be very helpful to have and a lot of low budget teams rely heavily on the old SRX and SPX controllers being resold.

2 Likes
16

I don’t disagree. I remember them saying that was one of the reasons it likely won’t happen at champs when I asked for it.

1 Like
17

On Brushed Controllers/Phoenix v5:

I can understand the concern here - to clarify, “legacy” is being used here because those products are not one of the modern and CAN FD capable products. There’s no intent for product support to be discontinued on the SRX/SPX.

We agree that this would be useful - unfortunately there are other factors that make this extremely difficult.

I originally discussed some of this on Discord after our attempts to bring better units to Phoenix v5 a few years ago, and I can summarize it a bit - essentially, to make changes to the units of Phoenix (in a way that doesn’t cause more confusion than it solves) requires substantial changes at every level of the software and firmware.

This is the reason the Quality-of-Life features like units/timestamps/signals were only introduced in the new API, and why they can’t easily be backported to Phoenix v5.

The corollary is that to bring products forward into the v6 API requires their firmware to be completely re-written from the ground up. While this was an obvious choice to make for our most recent products, the usage rates of brushed controllers and other older products make it a difficult decision to invest the substantial effort required. The additional limitation of these older products not having the hardware required for CAN FD further impacts that.

That’s not to say we would never bring those products forward, but it’s not currently on our roadmap.

On Phoenix v6 Questions

Correct

The firmware will automatically fall back to the closest non-Pro alternative. In the case of FOC this means falling back to traditional trapezoidal commutation; in the case of something like Fused CANcoder, this means falling back to a traditional Remote CANcoder usage.

Additionally an appropriate StatusCode will be returned (where possible) and an error message will be reported to the DS console.

For features that don’t have a non-Pro alternative (such as TorqueCurrentFOC control) the device will not enable and will set an explicit Fault & Sticky Fault, and will also blink the ‘unlicensed’ blink code (Red/Green).

Note that the only features that don’t have a non-Pro alternative are the Torque output control modes; any future features that may not have a direct fallback will have a behavior appropriate to the feature.

Not in the current release, but it’s on our high-priority list for addition in the off-season.

Right now to check license status you would need to look at the device entry in Phoenix Tuner X.

10 Likes
18

I’ve been experimenting with the Phoenix 6 API and have a few “complaints” & possible improvements.

Slots

First of all, the Slot0Configs, Slot1Configs, and Slot2Configs classes are all unique classes and don’t have a common base class. Ultimately this can result in ugly scenarios like this (this function takes in a PIDVS constants class and a slot number):

image
image462×530 38.4 KB

That redundant code suggests to me there’s probably a better way to do this; i.e. a single SlotConfig class that does all the current ones do, but stores the slot number in the class, allowing you to construct something like new SlotConfig(slotNum) and apply the configuration from there. It would simplify code that relies on being able to cleanly pass in parameters.

PID Constants

The migration docs refer to feedforward as kF while the API refers to it as kV. Small nitpick but did confuse me a bit.

Voltage Comp vs. Duty Cycle Out

In a similar vein to the old system of voltage compensation, to simplify being able to switch between voltage compensation and no voltage compensation, it would make sense (to me at least) to have single classes for each closed-loop type and have a parameter for voltage compensation, rather than explicit classes.

16 Likes
19

FOC still being behind a pay wall makes me sad.

I’m sure it was fairly complicated and costly of CTRE’s time, and we’d be happy to pay additional for it. But the per license adds up. At this point our drive system was 13 CTRE devices (among other Falcons on the system) and the cost to buy a license for each one for a small performance gain wouldn’t be worth it.

5 Likes
20

Our drive is on a canivore, at that point having the license for the canivore makes the most sense.

1 Like