With another season behind us, the CTR development team is looking for feedback on your experience with Phoenix v5 and Phoenix Pro in 2023.
We’re primarily looking to keep this about the software itself (libraries, Phoenix tuner, firmware, etc.) plus the general software user experience (the licensing process, finding what you need in documentation/examples, software update process, knowing that updates are available, etc.).
Peter outlined a very good feedback structure over in the WPILib Feedback thread so I’m going to shamelessly steal it here for your consideration:
Like most vendors and the WPILib folks this is our time of year for planning and prioritizing development work. We were excited to talk with many of you down at Houston and appreciate any further feedback from the folks here on CDChief Delphi.
Our staff discussion activity in this thread may be minimal while we’re still regrouping post-season, but I wanted to give everyone a chance to provide feedback while the season is still fresh in everyone’s minds. We’ll be looking at all your feedback (positive and negative) as we plan for the 2024 season.
If for some reason you’d rather share feedback privately or want to share general feedback at any point in the year, please email us at [email protected].
Note this email address is checked less frequently so for technical support or questions requiring a response please reach out to us through our normal phone/support/sales channels.
Found an issue (at least an issue to us) this year with using an analog feedback device (potentiometer) on a Talon SRX using LabVIEW. We set sensor phase to reverse but ran into lots of issues reading the current position with the get status VI. Finally opened Tuner to find out there was supposed to be a negative sign in front of the position but it was not reported as negative by LabVIEW. All sensor get statuses were positive, but when sending a position command, it needed to be negative to match what the Talon wanted. Was quite confusing to write logic using positive numbers when reading the position but needing to send negative numbers when sending a set position.
Also a major ask - can we please get Canonical Units in non-paid versions of Phoenix? I’m okay with paying for the extra features to open up control on certain controllers, but having Canonical units on all of the controllers would make teaching students so much easier when you don’t have to do weird conversion math.
Also worth noting: CTRECross The Road Electronics has been publicly talking about, promising, and delaying this feature for years. It’s extremely frustrating to see a fundamental convenience/approachability/usability feature that people have wanted/expected for over half a decade finally appear only behind a restrictive DRM scheme.
I implore CTRECross The Road Electronics to remember that this is an educational program for high-schoolers, and providing sensible unit handles is especially important for that audience.
Just wanted to pop in and say we appreciate both points of feedback - we’d like to keep the discussion open and unbiased so for the time being we’re going to hold off on responses to specific items, but we’re reading each of them and appreciate the insight and frankness.
Canivore utilization seems to be very underestimated. Started having major issues including a talon reboot when canivore report 45-46% utilization, went away immediately when dropping to 35-40% by reducing some traffic.
Also, motor controllers get very hot with FOC (v2 Falcons), 100°C after about 10 minutes or so of driving
Overall very pleased with the vast improvements on the API with Phoenix Pro
Each time we updated the firmware on a CANcoder, it would make every device on the CAN bus disappear in Phoenix Tuner, requiring three/four reboots to update the firmware on every CANcoder. This happened on the original and “version H” CANcoders, and no other CAN devices.
When a TalonFX is inverted using .setInverted(), then immediately after the encoder count is set using .setSelectedSensorPosition(), the encoder count doesn’t get set. This was noticeable for those with inverted swerve modules.
Overall though my experience programming CTR devices has been very positive this year, and other than some minor things like those examples I can’t think of any issues or annoyances programming with TalonFXs, CANcoders, and the CANivore.
First year for us using the Pigeon 2 on a robot on the field and we really liked it. It worked well for us.
First competition year for us with the canivore and we ran two of them… one for the RIO and one for the Jetson. Both seemed to work without any major issues from the Canivore… the biggest issues were likely something to do with our end of things.
We used the CANdle for the first time this year with LEDs to drive feedback and that was a huge win but we did run into some issues with the docs being unclear… I think we chalked that up to just our own error. Maybe more examples for the candle are needed?
We continue to run most of our control software off of the Jetson(s) on our robot and that enables us to a ton of cool stuff and we love having all of the packages available to us to do that.
The new app in the windows store seemed to work really well but there was a moment of panic at an event where we didn’t have it downloaded and installed with the latest firmware. I think there is an offline version now but making that available would be good.
Would love to see more support for Python and documentation for that.
We are just now dipping our toes into the waters for the pro features - this season wasn’t the time for us to make the leap but we are carefully watching it and starting to develop for it.
I am a mentor for what I would call a middle-class resource team. We do tear down robots and recycle their parts to save funds, but we generally have enough funds year over year.
We won’t be paying for Pro, because at the control level I don’t think we’re getting value for our dollar on the licensing, at least I can’t figure out what we’d be getting that would be worth the thousands of dollars we’d spend there.
I think that the feedback I have for the CTRE team would be: If you want more Phoenix Pro subscribers, you should clean up your Phoenix v5 API. My team is likely the exact demographic you need for your growth, but the major hurdle you have to overcome is to convince a mentor like me that it’s worth it.
The Phoenix v5 API is so convoluted that the barrier of entry for students learning it is only accessible to the most curious and driven minds. When I first start teaching the students how to calculate kP and kF for closed-loop control, I refer to the measurement as Spacebucks. The units per 100ms is so arbitrary to the high school kid’s mind, that it is equivalent to some non-sensical measurement like spacebucks. We then teach them how to use Phoenix Tuner to measure spacebucks and all that jazz, but in the end the unit conversion is so weird it is a MASSIVE stumbling block for newer robotics students.
So, I would echo Oblarg’s comments in that pushing standard units to the v5 API should be something that you do. Not only because it’s been spoken of as an upcoming feature for many years (without having to pay for accessibility) but because it will make good business sense. Getting your middle class teams like mine to be fully conversant in Phoenix v5 more rapidly, will ultimately push those teams to the edge where more full control through the Phoenix Pro API will make actual business sense and we’d pull the trigger.
if you have enough falcons that $10/device adds up to thousands of dollars, I recommend investing in a CANivore to access the $100/robot pricing. Even if you don’t go with Pro API, it will enable increased data throughput on v5 with CANController Area Network FD.
My broader point is that the discussion doesn’t benefit from pricing hysterics. Even with 20 falcons on your robot, $200/season is comparable to 1 whole-team meal (16 bodies x $12, San Francisco Bay Area).
We have 4 Falcons on the robot this year. Late in the season we were struggling to get the v5 API to run good position control (which I traced to nonsense units being part of the problem), so I pulled the trigger on Pro licenses. Unfortunately even with the improved API we ended up sticking with position loops on the RIO due to lack of documentation/examples in Pro and 1 week before we hit competition carpet.
(The RIO loops had been hard to tune, but we slowed the arm down 3x via a planetary and that made the system easy enough to do on the RIO via naive proportional control)
I’m not a programmer on our team so I can’t really give any specific feedback, but I do think I can speak for our programmers when I say that I think we were all under the impression that the conversion from Phoenix v5 to Pro would be significantly easier/faster than it was.
About mid-way through the season we bought a bunch of licenses to upgrade primarily our swerve drive system (as well as some other mechanisms) to Phoenix Pro for the various performance benefits it promised and ended up downgrading all of them after realizing the amount of effort it was going to take to make the drive system work correctly again after the change (due to the limited time we had between events). Maybe this was just our own impression, but I think we thought it was going to be much closer to a “drop-in” solution than it ended up being.
Perhaps having an “upgrade guide” of some sort that documents the differences between v5 and Pro and highlights the things to watch out for when switching over would be beneficial and allow more teams to take advantage of Pro without having to rewrite significant portions of their code from scratch or get confused as to why previously working functionality no longer works after upgrading.
On a somewhat unrelated note (and while not specifically related to v5 or Pro), I, for one, would appreciate it if there was proper support for running CANivore in “Standard” CAN mode rather than limiting it to CAN FD. CAN FD is nice and all, but what our team really needed this year was two standard CAN busses, due to the nature of how we wire our CAN network. While the additional feature of CAN FD are nice for some, I’m partial to the reliability (and flexibility) of the Standard CAN bus, and being able to offload some of our bus traffic (and maybe even support non-CTRE CAN devices) would be a huge benefit to some teams.
The talonfx encoder seemed to randomly stop counting, meaning reported velocity was always 0. Further investigation revealed this happened when reaching a high number of rotor ticks, seemed to be around the 8bit integer limit. Resetting rotor ticks to zero did not fix the issue unfortunately, only a restart would. This started happeniny every 3 or so minutes due to the gear ratio on one of our constantly spinning mechanisms.
Surfacing of bus diagnostic information to the robot code space would be really nice. As far as we could tell, there was no way to access items like these:
CAN bus utilization (on CANivore, only accessible now though the command-line utility and Tuner?)
Transmit error counter
Receive error counter
CRC/Form/Stuff error
Bus condition (Bus OFF/HEAVY/LIGHT)
With CAN bus wiring issues being a prolific source of robot woes, any insight into the state of the bus from the robot software, which we could then log or send directly to the driver station, would be huge.
At a minimum, it would be great to see these be exposed on the CANivore and surfaced through the Phoenix library.
Even better would be having them also surfaced on other CAN devices, like the TalonFX. With this info logged, it might even be possible to catch a failing CAN bus connection before it completely goes out by seeing where the errors start materializing along the chain. As it stands now though I think we just don’t have the information expoed to do that.
For example, if every TalonFX could send out it’s CAN TX error counter, you might be able to see that every device after some daisy-chain point starts incrementing it’s error counter (since it has an intermittent connection, and that value get’s transmitted and logged when it briefly rejoins the bus). Most robot CAN failures I’ve seen are intermittent. Maybe, almost automatically, with no additional hardware, your logs could tell you where your CAN bus broke. My robot code telling me where a wire probably broke would be pretty magical.
I’m not saying this would work for sure - the terminator dropping off the bus at the end of the run sometimes might kill every device on it, but maybe not. I’ve seen CAN busses run (poorly, but run) with just one terminator before. The point is we can’t even try this out at the moment, and it seems like a cool opportunity to me.
I don’t think my math is off, but okay. We keep three-ish robots in a few form factors (for training) plus our competition robot for a year. So I can pay 1200 up front in CANivores, for the privilege of only paying 100 per robot or I can pay $10 a year for a perpetual (yet, non-transferrable) license for each device.
How many years will my (or your) team be doing this dance before the price point gets to thousands?
I don’t think it’s pricing hysteria at all, and from what I can tell in your post we at least agree that there is a fairly standard use-case where there isn’t even a marginal benefit provided.
Our shoulder joint had two falcons, and we set one to follow and invert. When we tried to apply a position control setting via the falcon onboard loops, the left and right sides did not do the same things at the same time. I expected that I should have been able to have the second follow the first regardless of mode?
We ended up doing the position control via the Rio and writing power% to the lead falcon.
Hopefully the V5 docs get up to the same quality as the pro docs. Unless only paying users will get to have the benefits of the nicer docs, I have had a hard time understanding the setup of the V5 docs for a while.
Candle firmware bug caused our SparkMaxs to act dead. Easy to fix once figured out.
Ugly:
CAN coder absolute mode for swerve. So many posts all season from teams needing non stop help. CTRE engineers were on it trying to help but this had to be the number one issue with swerve software this season. Please, please make this easier for people.
And for what it is worth I do appreciate the need to change your business model.
Having Pro and v5 be completely different APIs and Pro being needed to unlock FOC made it pretty scary to do a mid-season upgrade even to just add FOC the drive motors. It was hard to make sure all our configuration code etc was being updated correctly.
I know maintaining and upgrading APIs is not easy, but I wonder if it would be better to make the new API (with all the signal objects etc) available on v5, and just have FOC and time sync etc not be available unless you were using Pro? That would make it possible to update the code while keeping everything at v5, and then upon upgrading to pro just having to add .withEnableFOC(true). I understand if unit changes need to stay as pro-only because it’s in firmware, but config and signal objects were also a massive change.
TLDR Changing one thing (FOC) mid-season is risky enough as is, adding the big API change on top of that did not help.
On this note, something you could have is an API migration tool, which is a fake version of v5 in sim where whenever a v5 function is called, instead of doing it, it just prints out the pro version of that call (or dumps it file in a csv with columns filename, linenumber, oldline, newline).
