2019 Kickoff Release of CTRE Phoenix

Technical Programming
, , , , ,
#1

2019 CTRE Phoenix Release

As of this post, CTRE Phoenix for 2019 FRC is now available!

This release is compatible with GradleRIO and VSCode, and also introduces the new Phoenix Tuner tool. The software API is almost 100% compatible with the 2018 API (with a couple minor exceptions listed in our documentation). Read on for more information on the components of this release:

Phoenix Installer

The installer for CTRE Phoenix can be found in the same location as last year.
A Windows installer (our recommended method of installing Phoenix) and a zip of components for non-windows machines are both available.

Firmware

The minimum necessary device firmware has changed - Talon SRX and Victor SPX will both require at least firmware version 4.11, and CANifier and Pigeon IMU will require at least version 4.0. These are available via the Phoenix installer and the individual product pages on the CTRE website.

Documentation and Blog

Last year, we transitioned the most-used portions of our documentation to GitHub, while reference material remained in the separate Software Reference Manual.

This year, we’ve gone one step further - we’ve moved all of our documentation to the ReadTheDocs platform, including documentation formerly in the Software Reference Manual. There are a couple of advanced topics still being migrated, but the new docs cover the majority of use cases.

https://phoenix-documentation.readthedocs.io/en/latest/index.html

This platform allows for easy navigation and robust formatting, and at any time you can download a pdf file of the documentation for offline use.

While it’s been in development we’ve kept the source documentation private, but we have now updated our Phoenix-Documentation repository as the source for our ReadTheDocs site. We welcome contributions from any community members, and we can’t wait to hear your feedback.

One other feature this brings is a Blog! Our main ReadTheDocs page will be updated periodically with information on new features and updates. Right now, it has all the information on our new features and changes for 2019 - this includes lots of things that wouldn’t fit in this announcement post.

Phoenix Tuner

As some of you are already aware, Silverlight is no longer supported on the roboRIO for 2019 - this means the previous web-interface CAN plug-in for updating and configuring CAN devices no longer works.

As a replacment (and expansion!) for these features, we’re introducing a new tool called Phoenix Tuner.

This is a Windows application that interfaces with the roboRIO to provide all the tools you need to successfully use our CAN devices (including PDP and PCM). In addition to the firmware and device ID updating features, Phoenix Tuner includes:

  • Ability to Firmware-update all devices of one type at the same time
  • Expanded Self-test Capabilities (no more character limit!)
  • Ability to Configure all persistent device parameters
  • Ability to control a Talon SRX or Victor SPX in Percent Output mode (typically requires the Driver Station to enable)
  • Built-in data plotter for Motor Controllers

We’ll be continually expanding on the features that Phoenix Tuner offers - there’s no specific timeline, but planned future features include support for additional control modes and additional plotting features.
The latest release will always be available on the GitHub repository linked above, and the Phoenix installer will always include the latest version of Phoenix Tuner at the time of publish.

…and More!

There are more API features and information that wouldn’t fit in this post, so check out our documentation for all the details.

Good Luck this Season!

12 Likes
WPIlib 2019: Adding 3rd Party Libraries
Arcade drive
#2

Thanks for the update folks!

If I’m reading the docs correctly, it appears that every PC that will build and deploy robot code has to have Pheonix installed on it via the installer or .zip provided. Nope I can’t read .

#3

This actually isn’t the case. As long as you have an internet connection and have added Phoenix as a vendor dependency to your project (see here), you can build and deploy any project that requires Phoenix on any machine that can build and deploy standard WPILib projects.

We highly recommend using the installer or zip on all machines, though, otherwise an internet connection will be mandatory.

#4

Note that this is only the case for your first build, since gradle will cache the fetched libraries indefinitely. If you delete your ~/.gradle directory (or run low on hard drive space), though, it will have to redownload.

If you can, installing the zip or running the .exe is preferred just to be safe (don’t want to be missing dependencies in the middle of a competition!)

#5

Excellent, thanks - I didn’t realize that step was actually updating the Gradle file.

Understood having the installer on all machines, we’ll take it into account. FYI from our side, we’re concerned about making sure one person can update the version of CTRE libraries required by our build, and everyone else gets that update automatically when they pull in that change (rather than having to know to go reinstall something manually). We’ll have internet at the shop for most of development, and will be sure the dev PC’s that come to competition are updated before we go.

All of this is me trying to soak up info late the night before, I’m sure I’ll start to answer a lot more of these process questions as we experiment over the next few days. Thanks again all for the hard work leading up to this!

#6

This will always be true because of the way projects are now set up. The json file that defines a vendor dependency lives in the project directory (projectDir/vendordeps/) - as long as that file is committed into version control, anyone who pulls the project will pick up those version requirements.

The issue is where the project pulls the actual dependency library files from - if they’re not present on your machine from the installer or haven’t been cached, they have to be pulled from the internet (specifically our maven repository).

So bottom line in an update scenario:

  1. One person can update the CTRE version and commit the change, then everyone can pick up that new version requirement.
  2. Everyone pulling the updated project should also install the new version of Phoenix if they want to be able to build offline.
#7

Ah ok, that seems super slick! Thanks for the explanation, that makes sense to me!

#8

Will https://github.com/CrossTheRoadElec/Phoenix-api be updated with 2019.1.1 source?

#9

I’m most excited for interpolation of motion profile setpoints :slight_smile:

1 Like
#11

Phoenix-api will be updated Monday

1 Like
#12

Out of curiosity, is this the correct location to query for this file?

EDIT: Nevermind, the docs confirmed this for me. Thanks anyway!

#14

Over the offseason, we developed our drivetrain position and velocity control using only the CTRE talon capabilities. While porting to the 2019 release, I found that the following line of code throws an error.

 configSensorTerm(SensorTerm.Sum0, FeedbackDevice.None, 0)

e: /Users/Ben/dev/robotics/5499/frc-2019/src/main/kotlin/org/team5499/frc2019/subsystems/Drivetrain.kt: (380, 62): Unresolved reference: None

I looked through the docs and noticed that “None” was removed from the “FeedbackDevice” enum and could not find a replacement. I could have overlooked something in the docs. Any solution to this?

#15

Looks like it was removed over the summer. FeedbackDevice.None wasn’t correct in 2018 either, it would select one of the other types due to a cast error. I think we intended on creating a new None value, but didn’t capture it in a tracker. It isn’t a very useful enum anway.

There is typically no need to config the sensor terms, if you are not using SensorSum or SensorDifference as your selected feedback type. Or just pass any type. Factory default selects Quad for both terms (same was true last year). You can confirm this by pressing “Factory Default” in Tuner, or use configFactoryDefault() in API.

If you are using SensorSum/SensorDiff and for some reason need to set one of the terms to a control value, you can…

  • Select FeedbackDevice.SensorSum for sum0. API allows this, though you will get a DS warning about it. Term will report zero - I just retested it using API and Tuner.
  • Select FeedbackDevice.RemoteFilter0 assuming RF0 is set to “off”. Just note you will see a remote sensor sticky fault if happen to select sensor sum.

Anyway it sounds like you are just porting, I would default to Quad to match configFactoryDefault().

Makes sense?

#16

Just to make sure I understand the changes that need made to use Motion Profile Arc. The boolean for auxPID needs set to true for each point and the duration needs switched to an integer. Am I missing anything?

#17

You’re not missing anything - those two items are the only changes needed for MotionProfileArc.

Is there an issue you’re running in to?

1 Like
#18

No issues, just trying to get BobTrajectory updated to reflect the new changes.

Thanks.

#19

Spent some time with this on Sunday - and wow does it have some awesome features. I like the ability to graph motor information real time and to be able to control motors from the interface. Very nice!

#20

Quick update

The public Phoenix-api repos is a bit further behind then we realized (since summer). It’s still being updated - but I expect it will be up this week - stay tuned.

In the meantime I would recommend using our compiled/tested binaries (like normal) by following our documented procedures.

Also note java teams can pull the sources-jar from your local repos (or our remote maven repos).
Or just control+click in VsCode our classes to look at stuff.

#21

That makes sense. Thank you. Another question:

I’m trying to port over to the new “SlotConfiguration” system for our control loops from setting everything manually. I noticed that I can only set a slot config for the primary slot (slotIdx = 0) but not the secondary slot (slotIdx = 1). I found a method that does not override the slot and timeoutMs but its marked private in the ctre library. I can work around this, but is there a way to set the slot #1?

#22

configureSlot() is used internally by our configAllSettings function.

configAllSettings() is our recommended way of setting all of the persistent configurations on our devices (including all of the slot parameters). It performs a factory default on the TalonSRX and then sets all of the new parameters (so no parameter should be at an unexpected value).

There’s a java example here:

Alternatively, you can still use last year’s method of individually setting the parameters (kP, kI, kD, etc.) with their respective config*() functions. If you use this method, we recommend calling configFactoryDefault() during initialization.

Regrading configureSlot() - as the new additions for the config* API evolved over the summer we ultimately decided to go with configAllSettings and didn’t intend for configureSlot() to be a commonly used function, which is why only the original overload is public (and not the full private API which has some non-public-facing optimization parameters). Given your question and that people may want to call configureSlot in niche use-cases, we’ll probably add a full configureSlot(slotConfig, slotIdx, timeoutMs) overload in a future release.