Phoenix 6 Documentation#

Welcome to the Phoenix 6 documentation. Individuals looking for Phoenix 5 documentation may locate it here.

The Phoenix 6 software framework allows you to control and configure your CTR Electronics Phoenix 6 Devices. Phoenix 6 represents a complete rewrite of the software framework over the existing Phoenix 5 framework. With Phoenix 6, users have access to many new features that expand the control the user has over their devices.

CTR Electronics Blog

For news and updates about your CTR Electronics device, please check out our blog.

Changelog

A changelog containing API, Tuner and Firmware changes is available here.

Migration Guide

A Phoenix 5 migration guide is available here.

Installation

Installation instructions for Phoenix API & Tuner.

Phoenix Tuner

Documentation that introduces the companion application to manage your CTR Electronics devices.

Hardware Reference

Documentation for device specific configuration, troubleshooting and setup instructions.

API Reference

Documentation and details on using the CTR Electronics device API. This includes usage of signals, configs, control requests, etc.

Examples

Software API examples for controlling your devices.

Troubleshooting

Common troubleshooting for hardware or software problems.

Installing Phoenix 6#

Installation of Phoenix 6 is comprised of a few steps

API Installation#

Phoenix 6 currently supports Java and C++ for development.

System Requirements#

The following targets are supported:

NI roboRIO
Windows 10/11 x86-64
Linux x86-64 (desktop)
- Ubuntu 22.04 or newer
- Debian Bullseye or newer
Linux ARM32 and ARM64 (Raspberry Pi, NVIDIA Jetson)
- Ubuntu 20.04 or newer
- Debian Bullseye or newer
macOS (regular simulation only)

Offline#

Important

Users on non-Windows devices should skip to the Online installation instructions.

Download the Phoenix Framework Installer
Navigate through the installer, ensuring applicable options are selected

Apply the vendordep via WPILib VS Code Adding Offline Libraries

Online#

Users in FRC can install Phoenix without an installer using WPILib’s Install New Libraries functionality in VS Code. This requires the user to have an installation of WPILib on their machine.

To begin, open WPILib VS Code and click on the WPILib icon in the top right.

Then type Manage Vendor Libraries and click on the menu option that appears. Click Install new libraries (online) and a textbox should appear. Follow the remaining instructions below on pasting the correct link into the textbox.

FRC (v6 Only)

Important

This vendordep is for robot projects that are only using devices with Phoenix 6 firmware.

Paste the following URL in WPILib VS Code Install new libraries (online):

https://maven.ctr-electronics.com/release/com/ctre/phoenix6/latest/Phoenix6-frc2023-latest.json

FRC (v6 & Phoenix 5)

Important

This vendordep is for robot projects that are using both Phoenix 6 devices & Phoenix 5 devices.

Paste the following URL in WPILib VS Code Install new libraries (online):

https://maven.ctr-electronics.com/release/com/ctre/phoenix6/latest/Phoenix6And5-frc2023-latest.json

Important

Devices on Phoenix 6 firmware must use the Phoenix 6 API. Device on Phoenix 5 firmware must use the Phoenix 5 API.

non-FRC (Linux)

Phoenix 6 is distributed through our APT repository. Begin with adding the repository to your APT sources.

sudo curl -s --compressed -o /usr/share/keyrings/ctr-pubkey.gpg "https://deb.ctr-electronics.com/ctr-pubkey.gpg"
sudo curl -s --compressed -o /etc/apt/sources.list.d/ctr<year>.list "https://deb.ctr-electronics.com/ctr<year>.list"

Note

<year> should be replaced with the year of Phoenix 6 software for which you have purchased licenses.

After adding the sources, Phoenix 6 can be installed and updated using the following:

sudo apt update
sudo apt install phoenix-pro

Tip

To get a robot application up and running quickly, check out our non-FRC Linux example.

Tuner X Installation#

Phoenix Tuner X is a modern version of the legacy Phoenix Tuner v1 application that is used to configure CTRE Phoenix CAN devices.

Phoenix Tuner X is supported on Android, Windows 10 (build 1903+), and Windows 11. Installation is available from the respective OS stores.

Running the Diagnostic Server#

Phoenix Tuner utilizes an on-device HTTP server called Phoenix Diagnostic Server to communicate with the device. The user can run the diagnostic server through one of two ways.

1: Deploying a Robot Program#

Phoenix Diagnostics will automatically run assuming you have instantiated a CTR Electronics device in your robot program. This can be as simple as having a motor declared somewhere in your program.

Note

The ID of the device does not need to be valid to run diagnostics.

Java

private TalonFX m_motor = new TalonFX(0);

C++

hardware::TalonFX m_talonFX{0};

When the program runs, it will print text to the console similar to the below

Note

WPILib users will see this text in the Driver Station or RioLog

[phoenix] Starting Standalone Diagnostics Server (23.1.0-Jun  2 2023,23:17:09)
[phoenix-diagnostics] Server 2023.1.0 (Jun  2 2023, 23:17:56) running on port: 1250

2: Running Temporary Diagnostic Server#

Alternatively, users can run a temporary diagnostic server in Tuner X. The temporary diagnostic server will only run until the next reboot of the target system.

Configuring your Device#

All CTR Electronics devices have an ID that distinguishes multiple devices of the same type on the same CAN bus. This should be configured to the user’s preference. Firmware upgrading is also generally required for each new release of Phoenix 6 API. Please visit the relevant Tuner pages on how to complete these steps.

Updating Firmware

Click here to visit the section on updating your device firmware

Configuring IDs

Click here to visit the section on configuring your device ID

New to Phoenix#

Phoenix 6 currently offers the following features and will further expand.

Phoenix 6#

The following features are available for free in the Phoenix 6 API.

Comprehensive API #

Device signal getters return a StatusSignal object, expanding the functionality of status signals.
Control devices with an extensive list of flexible, strongly-typed control request objects.

Canonical Units#

Uses the popular Units library for C++ and standardizes on SI units.
Signals are documented with the unit type and the minimum and maximum values.

Improved Device Control#

New and improved control output types and closed-loop configuration.
Improved Motion Magic® with jerk control and support for modifying the profile on the fly.
Kalman-based algorithms to reduce latency while maintaining smooth data.

Enhanced Support for CAN FD #

Improved CAN FD framing further reduces any CAN bus utilization issues.
Larger CAN frames allow for the addition of more advanced features.

New Tuner X Self Tests #

Detailed and resolute self tests to improve debugging.

Free High-Fidelity Simulation #

Simulation closely follows the behavior of real hardware.
Write unit-tests for your robot code, and make sure the robot works before deploying.

Continuous Wrap Mode #

Takes the shortest path for continuous mechanisms.
Ideal for mechanisms such as Swerve Drive Steer.

Phoenix Pro#

Certain Phoenix 6 features require the device or CANivore to be Pro licensed. The list of features that require licensing is available below.

Field Oriented Control (FOC)#

~15% increase in peak power.
Increased torque output; faster acceleration and higher speeds under load.
Greater efficiency; the motor draws less current for the same output power, increasing battery life.
Support for direct torque control.

Time Base Synchronization#

Using CANivore Timesync, signals from all devices are sampled and published to the CAN bus at the same time.
API can synchronously wait for data from multiple devices on a CANivore to arrive.

Fused CANcoder#

Fuse a CANcoder with the motor’s internal rotor, getting absolute data all the time while using the fast internal sensor for closed looping.

Feature Breakdown#

A full comparison of features between the free Phoenix 6 API and Phoenix Pro is shown below.

Feature	Phoenix 6	Phoenix Pro
Canonical Units	x	x
Improved Bus Utilization	x	x
CANcoder Always Absolutely	x	x
Kalman-based Velocity	x	x
Synchronous Wait for Data	x	x
System + CANivore Timestamps	x	x
Explicit Control Requests	x	x
Continuous Wrap Mode	x	x
Improved Self-Test Snapshot	x	x
Tuner X Improved Plotting	x	x
Time-Synced Signal Publishing		x
Field Oriented Control (FOC)		x
CAN Device Timestamps		x
Fused CANcoder + TalonFX		x

API Migration#

This section serves as a “cheat sheet” of commonly-used functions in Phoenix 5 and their equivalents in Phoenix 6.

Configuration
- Configuring device configs in robot code
Status Signals
- Using status signals to retrieve sensor data from devices
Control Requests
- Using control requests to control the functionality of actuators, such as the TalonFX
Closed-Loop Control
- Configuring and using closed-loop control requests
Feature Replacements
- Other features replaced or improved upon in Phoenix 6

Status Signals#

Phoenix 6 expands the functionality of status signals with the introduction of the StatusSignal (Java, C++).

Note

For more information about status signals in Phoenix 6, see Status Signals.

Using Status Signals#

Java

// get latest TalonFX selected sensor position
// units are encoder ticks
int sensorPos = m_talonFX.getSelectedSensorPosition();

// latency is unknown
// cannot synchronously wait for new data

C++

// get latest TalonFX selected sensor position
// units are encoder ticks
int sensorPos = m_talonFX.GetSelectedSensorPosition();

// latency is unknown
// cannot synchronously wait for new data

Java

// acquire a refreshed TalonFX rotor position signal
var rotorPosSignal = m_talonFX.getRotorPosition();

// because we are calling getRotorPosition() every loop,
// we do not need to call refresh()
//rotorPosSignal.refresh();

// retrieve position value that we just refreshed
// units are rotations
var rotorPos = rotorPosSignal.getValue();

// get latency of the signal
var rotorPosLatency = rotorPosSignal.getTimestamp().getLatency();

// synchronously wait 20 ms for new data
rotorPosSignal.waitForUpdate(0.020);

C++

// acquire a refreshed TalonFX rotor position signal
auto& rotorPosSignal = m_talonFX.GetRotorPosition();

// because we are calling GetRotorPosition() every loop,
// we do not need to call Refresh()
//rotorPosSignal.Refresh();

// retrieve position value that we just refreshed
// units are rotations, uses the units library
auto rotorPos = rotorPosSignal.GetValue();

// get latency of the signal
auto rotorPosLatency = rotorPosSignal.GetTimestamp().GetLatency();

// synchronously wait 20 ms for new data
rotorPosSignal.WaitForUpdate(20_ms);

Changing Update Frequency (Status Frame Period)#

Java

// slow down the Status 2 frame (selected sensor data) to 5 Hz (200ms)
m_talonFX.setStatusFramePeriod(StatusFrameEnhanced.Status_2_Feedback0, 200);

C++

// slow down the Status 2 frame (selected sensor data) to 5 Hz (200ms)
m_talonFX.SetStatusFramePeriod(StatusFrameEnhanced::Status_2_Feedback0, 200);

Java

// slow down the position signal to 5 Hz
m_talonFX.getPosition().setUpdateFrequency(5);

C++

// slow down the position signal to 5 Hz
m_talonFX.GetPosition().SetUpdateFrequency(5_Hz);

Important

Currently in Phoenix 6, when different status signal frequencies are specified for signals that share a status frame, the last specified frequency is applied to the status frame. As a result, users should apply the slowest status frame frequencies first and the fastest frequencies last.

Common Signals#

Several status signals have changed name or form in Phoenix 6.

General Signals#

Phoenix 5	Phoenix 6
`BusVoltage`	`SupplyVoltage`
`Faults` / `StickyFaults` (fills an object)	`Fault_` / `StickyFault_` (individual faults)
`FirmwareVersion`	`Version`

Talon FX Signals#

Phoenix 5	Phoenix 6
`MotorOutputPercent`	`DutyCycle`
`StatorCurrent`	`StatorCurrent` (motoring +, braking -), `TorqueCurrent` (forward +, reverse -)
`Inverted` (true/false; matches `setInverted`)	`AppliedRotorPolarity` (CCW+/CW+; typically matches `Inverted` config, affected by follower features)
`SelectedSensorPosition` / `SelectedSensorVelocity`	`Position` / `Velocity`
`IntegratedSensor*` (in `SensorCollection`)	`Rotor*`
`ActiveTrajectory*` (only Motion Magic® and the Motion Profile Executor)	`ClosedLoopReference*` (all closed-loop control requests)
`IsFwdLimitSwitchClosed` / `IsRevLimitSwitchClosed` (true/false)	`GetForwardLimit` / `GetReverseLimit` (Open/Closed)

CANcoder Signals#

Phoenix 5	Phoenix 6
`MagnetFieldStrength`	`MagnetHealth`

Pigeon 2 Signals#

Note

Many Pigeon 2 signal getters in Phoenix 5 fill an array, such as YawPitchRoll. In Phoenix 6, these signals have been broken up into their individual components, such as Yaw, Pitch, and Roll.

Phoenix 5	Phoenix 6
`RawGyro`	`AngularVelocity*`
`6dQuaternion`	`Quat*`
`BiasedAccelerometer`	`Acceleration*`
`BiasedMagnetometer`	`MagneticField*`
`RawMagnetometer`	`RawMagneticField*`

Control Requests#

Phoenix 6 provides an extensive list of flexible control modes through the use of strongly-typed control requests.

Note

For more information about control requests in Phoenix 6, see Control Requests.

Control Types#

In Phoenix 6, voltage compensation has been replaced with the ability to directly specify the control output type.

All control output types are supported in open-loop and closed-loop control requests.

Open-loop Control Requests#
Phoenix 5	Phoenix 6
PercentOutput	DutyCycleOut
PercentOutput + Voltage Compensation	VoltageOut
Phoenix 5 does not support torque control	TorqueCurrentFOC (requires Pro)
Current closed-loop	This has been deprecated in Phoenix 6. Users looking to control torque should use TorqueCurrentFOC (requires Pro) Users looking to limit current should use supply and stator current limits

Closed-loop Control Requests#
Phoenix 5	Phoenix 6
Position	PositionDutyCycle
Velocity	VelocityDutyCycle
MotionMagic	MotionMagicDutyCycle
Closed-loop + Voltage Compensation	{ClosedLoop}Voltage
Closed-loop + Torque Control (not supported in Phoenix 5)	{ClosedLoop}TorqueCurrentFOC (requires Pro)

Closed-Loop Control#

Phoenix 6 enhances the experience of using onboard closed-loop control through the use of standardized units and a variety of control output types.

Note

For more information about closed-loop control in Phoenix 6, see Closed-Loop Control.

Closed-Loop Setpoints#

Phoenix 6 uses canonical units for closed-loop setpoints.

Setpoint Conversion
	Name	Value	Units	Formula
Position	Original		\(\mathrm{raw\_units}\)	\(x_{\mathrm{old}}\)
Position	New		\(\mathrm{rotations}\)	\(x_{\mathrm{new}}=x_{\mathrm{old}} \cdot \frac{1}{2048} \frac{\mathrm{rot}}{\mathrm{raw\_unit}}\)
Velocity	Original		\(\frac{\mathrm{raw\_units}}{\mathrm{100ms}}\)	\(v_{\mathrm{old}}\)
Velocity	New		\(\frac{\mathrm{rot}}{\mathrm{second}}\)	\(v_{\mathrm{new}}=v_{\mathrm{old}} \cdot \frac{1}{2048} \frac{\mathrm{rot}}{\mathrm{raw\_unit}} \cdot 10 \frac{\mathrm{100ms}}{\mathrm{second}} \)
Acceleration	Original		\(\frac{\mathrm{raw\_units}}{\mathrm{100ms} \cdot \mathrm{second}}\)	\(a_{\mathrm{old}}\)
Acceleration	New		\(\frac{\mathrm{rot}}{\mathrm{second}^2}\)	\(a_{\mathrm{new}}=a_{\mathrm{old}} \cdot \frac{1}{2048} \frac{\mathrm{rot}}{\mathrm{raw\_unit}} \cdot 10 \frac{\mathrm{100ms}}{\mathrm{second}} \)

Closed-Loop Gains#

Position without Voltage Comp#

Phoenix 5 ControlMode.Position with voltage compensation disabled maps to the Phoenix 6 PositionDutyCycle control request.

Position without Voltage Compensation
	Name	Value	Units	Formula
kP	Original		\(\frac{\mathrm{raw\_output}}{\mathrm{unit}}\)	\(kP_{\mathrm{old}}\)
kP	New		\(\frac{\mathrm{duty\_cycle}}{\mathrm{rot}}\)	\(kP_{\mathrm{new}}=kP_{\mathrm{old}} \cdot 2048 \frac{\mathrm{unit}}{\mathrm{rot}} \cdot \frac{1}{1023} \frac{\mathrm{duty\_cycle}}{\mathrm{raw\_output}}\)
kI	Original		\(\frac{\mathrm{raw\_output}}{\mathrm{unit} \cdot \mathrm{millisecond}}\)	\(kI_{\mathrm{old}}\)
kI	New		\(\frac{\mathrm{duty\_cycle}}{\mathrm{rot} \cdot \mathrm{second}}\)	\(kI_{\mathrm{new}}=kI_{\mathrm{old}} \cdot 2048 \frac{\mathrm{unit}}{\mathrm{rot}} \cdot \frac{1}{1023} \frac{\mathrm{duty\_cycle}}{\mathrm{raw\_output}} \cdot 1000 \frac{\mathrm{millisecond}}{\mathrm{second}}\)
kD	Original		\(\frac{\mathrm{raw\_output}}{\mathrm{unit} / \mathrm{millisecond}}\)	\(kD_{\mathrm{old}}\)
kD	New		\(\frac{\mathrm{duty\_cycle}}{\mathrm{rot} / \mathrm{second}}\)	\(kD_{\mathrm{new}}=kD_{\mathrm{old}} \cdot 2048 \frac{\mathrm{unit}}{\mathrm{rot}} \cdot \frac{1}{1023} \frac{\mathrm{duty\_cycle}}{\mathrm{raw\_output}} \cdot \frac{1}{1000} \frac{\mathrm{second}}{\mathrm{millisecond}}\)

Position with Voltage Comp#

Phoenix 5 ControlMode.Position with voltage compensation enabled has been replaced with the Phoenix 6 PositionVoltage control request, which directly controls voltage.

Position with Voltage Compensation
Voltage Compensation Value:
	Name	Value	Units	Formula
kP	Original		\(\frac{\mathrm{\mathrm{raw\_output}}}{\mathrm{unit}}\)	\(kP_{\mathrm{old}}\)
kP	New		\(\frac{\mathrm{V}}{\mathrm{rot}}\)	\(kP_{\mathrm{new}}=kP_{\mathrm{old}} \cdot 2048 \frac{\mathrm{unit}}{\mathrm{rot}} \cdot \frac{1}{1023} \frac{\mathrm{duty\_cycle}}{\mathrm{raw\_output}} \cdot \mathrm{V\_comp} \frac{\mathrm{V}}{\mathrm{duty\_cycle}}\)
kI	Original		\(\frac{\mathrm{\mathrm{raw\_output}}}{\mathrm{unit} \cdot \mathrm{millisecond}}\)	\(kI_{\mathrm{old}}\)
kI	New		\(\frac{\mathrm{V}}{\mathrm{rot} \cdot \mathrm{second}}\)	\(kI_{\mathrm{new}}=kI_{\mathrm{old}} \cdot 2048 \frac{\mathrm{unit}}{\mathrm{rot}} \cdot \frac{1}{1023} \frac{\mathrm{duty\_cycle}}{\mathrm{raw\_output}} \cdot 1000 \frac{\mathrm{millisecond}}{\mathrm{second}} \cdot \mathrm{V\_comp} \frac{\mathrm{V}}{\mathrm{duty\_cycle}}\)
kD	Original		\(\frac{\mathrm{\mathrm{raw\_output}}}{\mathrm{unit} / \mathrm{millisecond}}\)	\(kD_{\mathrm{old}}\)
kD	New		\(\frac{\mathrm{V}}{\mathrm{rot} / \mathrm{second}}\)	\(kD_{\mathrm{new}}=kD_{\mathrm{old}} \cdot 2048 \frac{\mathrm{unit}}{\mathrm{rot}} \cdot \frac{1}{1023} \frac{\mathrm{duty\_cycle}}{\mathrm{raw\_output}} \cdot \frac{1}{1000} \frac{\mathrm{second}}{\mathrm{millisecond}} \cdot \mathrm{V\_comp} \frac{\mathrm{V}}{\mathrm{duty\_cycle}}\)

Velocity without Voltage Comp#

Phoenix 5 ControlMode.Velocity with voltage compensation disabled maps to the Phoenix 6 VelocityDutyCycle control request.

Additionally, kF from Phoenix 5 has been replaced with kV in Phoenix 6.

Velocity without Voltage Compensation
	Name	Value	Units	Formula
kP	Original		\(\frac{\mathrm{raw\_output}}{\mathrm{unit} / \mathrm{100ms}}\)	\(kP_{\mathrm{old}}\)
kP	New		\(\frac{\mathrm{duty\_cycle}}{\mathrm{rot} / \mathrm{sec}}\)	\(kP_{\mathrm{new}}=kP_{\mathrm{old}} \cdot 2048 \frac{\mathrm{unit}}{\mathrm{rot}} \cdot \frac{1}{1023} \frac{\mathrm{duty\_cycle}}{\mathrm{raw\_output}} \cdot \frac{1}{10} \frac{\mathrm{sec}}{\mathrm{100ms}}\)
kI	Original		\(\frac{\mathrm{raw\_output}}{(\mathrm{unit} / \mathrm{100ms}) \cdot \mathrm{millisecond}}\)	\(kI_{\mathrm{old}}\)
kI	New		\(\frac{\mathrm{duty\_cycle}}{\mathrm{rot}}\)	\(kI_{\mathrm{new}}=kI_{\mathrm{old}} \cdot 2048 \frac{\mathrm{unit}}{\mathrm{rot}} \cdot \frac{1}{1023} \frac{\mathrm{duty\_cycle}}{\mathrm{raw\_output}} \cdot 1000 \frac{\mathrm{millisecond}}{\mathrm{second}} \cdot \frac{1}{10} \frac{\mathrm{sec}}{\mathrm{100ms}}\)
kD	Original		\(\frac{\mathrm{raw\_output}}{(\mathrm{unit} / \mathrm{100ms}) / \mathrm{millisecond}}\)	\(kD_{\mathrm{old}}\)
kD	New		\(\frac{\mathrm{duty\_cycle}}{\mathrm{rot} / \mathrm{second}^{2}}\)	\(kD_{\mathrm{new}}=kD_{\mathrm{old}} \cdot 2048 \frac{\mathrm{unit}}{\mathrm{rot}} \cdot \frac{1}{1023} \frac{\mathrm{duty\_cycle}}{\mathrm{raw\_output}} \cdot \frac{1}{1000} \frac{\mathrm{second}}{\mathrm{millisecond}} \cdot \frac{1}{10} \frac{\mathrm{sec}}{\mathrm{100ms}}\)
kF kV	Original		\(\frac{\mathrm{raw\_output}}{\mathrm{unit} / \mathrm{100millisecond}}\)	\(kF_{\mathrm{old}}\)
kF kV	New		\(\frac{\mathrm{duty\_cycle}}{\mathrm{rot} / \mathrm{second}}\)	\(kV_{\mathrm{new}}=kF_{\mathrm{old}} \cdot 2048 \frac{\mathrm{unit}}{\mathrm{rot}} \cdot \frac{1}{1023} \frac{\mathrm{duty\_cycle}}{\mathrm{raw\_output}} \cdot \frac{1}{10} \frac{\mathrm{second}}{\mathrm{100ms}}\)

Velocity with Voltage Comp#

Phoenix 5 ControlMode.Velocity with voltage compensation enabled has been replaced with the Phoenix 6 VelocityVoltage control request, which directly controls voltage.

Additionally, kF from Phoenix 5 has been replaced with kV in Phoenix 6.

Velocity with Voltage Compensation
Voltage Compensation Value:
	Name	Value	Units	Formula
kP	Original		\(\frac{\mathrm{\mathrm{raw\_output}}}{\mathrm{unit} / \mathrm{100ms}}\)	\(kP_{\mathrm{old}}\)
kP	New		\(\frac{\mathrm{V}}{\mathrm{rot} / \mathrm{sec}}\)	\(kP_{\mathrm{new}}=kP_{\mathrm{old}} \cdot 2048 \frac{\mathrm{unit}}{\mathrm{rot}} \cdot \frac{1}{1023} \frac{\mathrm{duty\_cycle}}{\mathrm{raw\_output}} \cdot \frac{1}{10} \frac{\mathrm{second}}{\mathrm{100ms}} \cdot \mathrm{V\_comp} \frac{\mathrm{V}}{\mathrm{duty\_cycle}}\)
kI	Original		\(\frac{\mathrm{\mathrm{raw\_output}}}{(\mathrm{unit} / \mathrm{100ms}) \cdot \mathrm{millisecond}}\)	\(kI_{\mathrm{old}}\)
kI	New		\(\frac{\mathrm{V}}{\mathrm{rot}}\)	\(kI_{\mathrm{new}}=kI_{\mathrm{old}} \cdot 2048 \frac{\mathrm{unit}}{\mathrm{rot}} \cdot \frac{1}{1023} \frac{\mathrm{duty\_cycle}}{\mathrm{raw\_output}} \cdot 1000 \frac{\mathrm{millisecond}}{\mathrm{second}} \cdot \frac{1}{10} \frac{\mathrm{second}}{\mathrm{100ms}} \cdot \mathrm{V\_comp} \frac{\mathrm{V}}{\mathrm{duty\_cycle}}\)
kD	Original		\(\frac{\mathrm{\mathrm{raw\_output}}}{(\mathrm{unit} / \mathrm{100ms}) / \mathrm{millisecond}}\)	\(kD_{\mathrm{old}}\)
kD	New		\(\frac{\mathrm{V}}{\mathrm{rot} / \mathrm{second}^{2}}\)	\(kD_{\mathrm{new}}=kD_{\mathrm{old}} \cdot 2048 \frac{\mathrm{unit}}{\mathrm{rot}} \cdot \frac{1}{1023} \frac{\mathrm{duty\_cycle}}{\mathrm{raw\_output}} \cdot \frac{1}{1000} \frac{\mathrm{second}}{\mathrm{millisecond}} \cdot \frac{1}{10} \frac{\mathrm{second}}{\mathrm{100ms}} \cdot \mathrm{V\_comp} \frac{\mathrm{V}}{\mathrm{duty\_cycle}}\)
kF kV	Original		\(\frac{\mathrm{\mathrm{raw\_output}}}{\mathrm{unit} / \mathrm{100ms}}\)	\(kF_{\mathrm{old}}\)
kF kV	New		\(\frac{\mathrm{V}}{\mathrm{rot} / \mathrm{second}}\)	\(kV_{\mathrm{new}}=kF_{\mathrm{old}} \cdot 2048 \frac{\mathrm{unit}}{\mathrm{rot}} \cdot \frac{1}{1023} \frac{\mathrm{duty\_cycle}}{\mathrm{raw\_output}} \cdot \frac{1}{10} \frac{\mathrm{second}}{\mathrm{100ms}} \cdot \mathrm{V\_comp} \frac{\mathrm{V}}{\mathrm{duty\_cycle}}\)

Using Closed-Loop Control#

Java

// robot init, set slot 0 gains
m_motor.config_kF(0, 0.05, 50);
m_motor.config_kP(0, 0.046, 50);
m_motor.config_kI(0, 0.0002, 50);
m_motor.config_kD(0, 4.2, 50);

// enable voltage compensation
m_motor.configVoltageComSaturation(12);
m_motor.enableVoltageCompensation(true);

// periodic, run velocity control with slot 0 configs,
// target velocity of 50 rps (10240 ticks/100ms)
m_motor.selectProfileSlot(0, 0);
m_motor.set(ControlMode.Velocity, 10240);

C++

// robot init, set slot 0 gains
m_motor.Config_kF(0, 0.05, 50);
m_motor.Config_kP(0, 0.046, 50);
m_motor.Config_kI(0, 0.0002, 50);
m_motor.Config_kD(0, 4.2, 50);

// enable voltage compensation
m_motor.ConfigVoltageComSaturation(12);
m_motor.EnableVoltageCompensation(true);

// periodic, run velocity control with slot 0 configs,
// target velocity of 50 rps (10240 ticks/100ms)
m_motor.SelectProfileSlot(0, 0);
m_motor.Set(ControlMode::Velocity, 10240);

Java

// class member variable
VelocityVoltage m_velocity = new VelocityVoltage(0);

// robot init, set slot 0 gains
var slot0Configs = new Slot0Configs();
slot0Configs.kV = 0.12;
slot0Configs.kP = 0.11;
slot0Configs.kI = 0.48;
slot0Configs.kD = 0.01;
m_talonFX.getConfigurator().apply(slot0Configs, 0.050);

// periodic, run velocity control with slot 0 configs,
// target velocity of 50 rps
m_velocity.Slot = 0;
m_motor.setControl(m_velocity.withVelocity(50));

C++

// class member variable
controls::VelocityVoltage m_velocity{0_tps};

// robot init, set slot 0 gains
configs::Slot0Configs slot0Configs{};
slot0Configs.kV = 0.12;
slot0Configs.kP = 0.11;
slot0Configs.kI = 0.48;
slot0Configs.kD = 0.01;
m_talonFX.GetConfigurator().Apply(slot0Configs, 50_ms);

// periodic, run velocity control with slot 0 configs,
// target velocity of 50 rps
m_velocity.Slot = 0;
m_motor.SetControl(m_velocity.WithVelocity(50_tps));

Motion Magic®#

Java

// robot init, set slot 0 gains
m_motor.config_kF(0, 0.05, 50);
// PID runs on position
m_motor.config_kP(0, 0.2, 50);
m_motor.config_kI(0, 0, 50);
m_motor.config_kD(0, 4.2, 50);

// set Motion Magic settings
m_motor.configMotionCruiseVelocity(16384); // 80 rps = 16384 ticks/100ms cruise velocity
m_motor.configMotionAcceleration(32768); // 160 rps/s = 32768 ticks/100ms/s acceleration
m_motor.configMotionSCurveStrength(3); // s-curve smoothing strength of 3

// enable voltage compensation
m_motor.configVoltageComSaturation(12);
m_motor.enableVoltageCompensation(true);

// periodic, run Motion Magic with slot 0 configs
m_motor.selectProfileSlot(0, 0);
// target position of 200 rotations (409600 ticks)
// add 0.02 (2%) arbitrary feedforward to overcome friction
m_motor.set(ControlMode.MotionMagic, 409600, DemandType.ArbitraryFeedforward, 0.02);

C++

// robot init, set slot 0 gains
m_motor.Config_kF(0, 0.05, 50);
// PID runs on position
m_motor.Config_kP(0, 0.2, 50);
m_motor.Config_kI(0, 0, 50);
m_motor.Config_kD(0, 4.2, 50);

// set Motion Magic settings
m_motor.ConfigMotionCruiseVelocity(16384); // 80 rps = 16384 ticks/100ms cruise velocity
m_motor.ConfigMotionAcceleration(32768); // 160 rps/s = 32768 ticks/100ms/s acceleration
m_motor.ConfigMotionSCurveStrength(3); // s-curve smoothing strength of 3

// enable voltage compensation
m_motor.ConfigVoltageComSaturation(12);
m_motor.EnableVoltageCompensation(true);

// periodic, run Motion Magic with slot 0 configs
m_motor.SelectProfileSlot(0, 0);
// target position of 200 rotations (409600 ticks)
// add 0.02 (2%) arbitrary feedforward to overcome friction
m_motor.Set(ControlMode::MotionMagic, 409600, DemandType::ArbitraryFeedforward, 0.02);

Note

The Motion Magic® S-Curve Strength has been replaced with jerk control in Phoenix 6.

Java

// class member variable
MotionMagicVoltage m_motmag = new MotionMagicVoltage(0);

// robot init
var talonFXConfigs = new TalonFXConfiguration();

// set slot 0 gains
var slot0Configs = talonFXConfigs.Slot0Configs;
slot0Configs.kS = 0.24; // add 0.24 V to overcome friction
slot0Configs.kV = 0.12; // apply 12 V for a target velocity of 100 rps
// PID runs on position
slot0Configs.kP = 4.8;
slot0Configs.kI = 0;
slot0Configs.kD = 0.1;

// set Motion Magic settings
var motionMagicConfigs = talonFXConfigs.MotionMagicConfigs;
motionMagicConfigs.MotionMagicCruiseVelocity = 80; // 80 rps cruise velocity
motionMagicConfigs.MotionMagicAcceleration = 160; // 160 rps/s acceleration (0.5 seconds)
motionMagicConfigs.MotionMagicJerk = 1600; // 1600 rps/s^2 jerk (0.1 seconds)

m_talonFX.getConfigurator().apply(talonFXConfigs, 0.050);

// periodic, run Motion Magic with slot 0 configs,
// target position of 200 rotations
m_motmag.Slot = 0;
m_motor.setControl(m_motmag.withPosition(200));

C++

// class member variable
controls::MotionMagicVoltage m_motmag{0_tr};

// robot init
configs::TalonFXConfiguration talonFXConfigs{};

// set slot 0 gains
auto& slot0Configs = talonFXConfigs.Slot0Configs;
slot0Configs.kS = 0.24; // add 0.24 V to overcome friction
slot0Configs.kV = 0.12; // apply 12 V for a target velocity of 100 rps
// PID runs on position
slot0Configs.kP = 4.8;
slot0Configs.kI = 0;
slot0Configs.kD = 0.1;

// set Motion Magic settings
auto& motionMagicConfigs = talonFXConfigs.MotionMagicConfigs;
motionMagicConfigs.MotionMagicCruiseVelocity = 80; // 80 rps cruise velocity
motionMagicConfigs.MotionMagicAcceleration = 160; // 160 rps/s acceleration (0.5 seconds)
motionMagicConfigs.MotionMagicJerk = 1600; // 1600 rps/s^2 jerk (0.1 seconds)

m_talonFX.GetConfigurator().Apply(talonFXConfigs, 50_ms);

// periodic, run Motion Magic with slot 0 configs,
// target position of 200 rotations
m_motmag.Slot = 0;
m_motor.SetControl(m_motmag.WithPosition(200_tr));

Motion Profiling#

The Motion Profile Executor is not supported in the current release of Phoenix 6. Users can use Motion Magic® or run a motion profile on the robot controller.

Feature Replacements#

In addition to the changes shown in the other sections, several other Phoenix 5 features have been replaced or improved upon in Phoenix 6.

Motor Invert#

In Phoenix 6, motor invert is now a persistent config (Java, C++) instead of a control signal.

Warning

Since invert is a persistent config, getting and setting motor inverts are now blocking API calls. We recommend that users only set the invert once at program startup.

Neutral Mode#

In Phoenix 6, Neutral mode is now available in API as a config (Java, C++). Many control requests also have the ability to override the neutral mode to either force braking (Java, C++) or force coasting (Java, C++).

Nominal Output#

The Talon FX forward and reverse Nominal Output configs have been removed in Phoenix 6.

The typical use case of the nominal output configs is to overcome friction in closed-loop control modes, which can now be achieved using the kS feedforward parameter (Java, C++).

Sensor Phase#

The Talon FX setSensorPhase() method has been removed in Phoenix 6.

The Talon FX integrated sensor is always in phase, so the method does nothing in Phoenix 5.
When using a remote sensor, you can invert the remote sensor to bring it in phase with the Talon FX.

Sensor Initialization Strategy#

The Talon FX and CANcoder sensors are always initialized to their absolute position in Phoenix 6.

Clear Position on Limit#

In Phoenix 5, users could configure the TalonFX to clear its sensor position (i.e. set to 0) when a limit switch is triggered. In Phoenix 6, this feature has been improved to allow users to specify the applied sensor position when a limit switch is triggered. This can be configured using the *LimitAutosetPositionValue configs (Java, C++).

Velocity Measurement Period/Window#

In Phoenix 6, the velocity rolling average window in Talon FX and CANcoder has been replaced with a Kalman filter, resulting in a less noisy velocity signal with a minimal impact on latency. As a result, the velocity measurement period/window configs are no longer necessary in Phoenix 6 and have been removed.

Integral Zone and Max Integral Accumulator#

Phoenix 6 automatically prevents integral windup in closed-loop controls. As a result, the Integral Zone and Max Integral Accumulator configs are no longer necessary and have been removed.

Features to Be Implemented#

The following Phoenix 5 features are not implemented in the current release of Phoenix 6 but are planned to be implemented in the future.

Feature	Status
Remote sensors and limits	High priority
Auxiliary PID	High priority
Orchestra	Normal priority
Talon FX PWM Input	Normal priority
CANdle Support	Normal priority

Features Omitted#

The following Phoenix 5 features have been omitted from Phoenix 6. While there are no plans for these features to be added, if there is customer demand for these features, they may be considered for addition in the future.

Feedback is welcome at feedback@ctr-electronics.com.

Motion Profile Executor
- Control requests are planned to be improved to cover many of the use cases of the Motion Profile Executor.
Allowable Closed-Loop Error

CAN Bus Utilization#

CTR Electronics goes through great efforts to make our products efficient on CAN Bus bandwidth. This article highlights the average default bandwidth utilization of supported Phoenix 6 devices. Users should keep total CAN Bus utilization below 90% to prevent any unexpected behavior. Information on changing the default CAN update frequency is available in the API documentation.

Note

Using Phoenix API will automatically start up a diagnostics server which adds a constant 0-5% total CAN Bus utilization.

Device	Phoenix 5 (CAN 2.0)	Phoenix 6 (CAN 2.0)	Phoenix 5 (CAN FD)	Phoenix 6 (CAN FD)
Talon FX	4.7%	4.1%	2.0%	1.8%
CANcoder	1.8%	1.7%	0.9%	0.9%
Pigeon 2	5.5%	3.1%	2.5%	1.3%

Device Licensing#

The following devices are eligible for single-device licensing:

TalonFX (Falcon 500)
Pigeon 2
CANcoder

Additionally, CANivore is supported for licensing. When a CANivore is licensed, all devices on that bus are Pro enabled without additional activation.

Important

All license activation and verification features are only available in Phoenix Tuner X. Phoenix Tuner v1 does not support licensing actions.

Purchasing a License#

Licenses can be purchased in the licensing section on the CTR Electronics store. Click here to purchase a license.

Once a license has been purchased, you will receive an email confirmation confirming your purchase. Once this email is received, the license should be visible in the list of licenses in Tuner X.

Activating a License#

Licenses are activated by first clicking on the LIC icon in the bottom right corner of the device card.

This will open up a screen which displays a list of currently attached licenses for that device. Click on the Activate a new license button on the bottom of the popup.

A list of purchased (but unattached) license seats are shown here. Click on the license you would like to redeem and press the Activate Selected License button to confirm redemption of that seat.

Warning

Users should be aware that license activation is permanent and irreversible

Once the activation is complete, the license will be downloaded to the device. In the event that Tuner X disconnects from the internet or from the robot before this completes, the license is still activated and available for download the next time Tuner X is connected to the internet/robot.

Activating a License without a Robot#

Devices that have been seen by Tuner X at least once will be available in Device History. This can be useful for licensing a device when disconnected from the robot.

Verifying Activation State#

An icon displaying the license state of your device is located in the bottom right of the device card.

Showing the Pro license icon in the bottom right of the card in Tuner X

The below table can be used to determine your device license state for troubleshooting.

State	Image	Description
Licensed		Device is licensed for the current version of Phoenix Pro API.
CANivore contains Licenses		CANivore contains at least one bus license, which it will use to remote-license all compliant CAN devices.
Pro Licensing Error		Device is licensed and there was an error communicating license state.
Licensing Error		Device is not licensed and there was an error communicating license state.
Not Licensed		Device is not licensed for this version of Phoenix Pro API.
Licensing Not Supported	Icon not present	Device does not support licensing or is using an incompatible firmware for device licensing.

Additionally, users can perform a Self Test to verify that the device has a valid license.

Troubleshooting#

Did you activate a license for this device?
- Clicking on the icon will show licenses that are attached to this device
Is the latest diagnostic server running?
- Check the version at the bottom of Tuner X’s devices page.
  - Latest version details can be found in the changelog under the latest Phoenix-Pro version.
- Confirm the vendordep in your robot project is the latest version.
- Alternatively, you can deploy the temporary diagnostic server.
Is the latest Pro firmware flashed onto the device?

Phoenix Tuner X#

What is Phoenix Tuner X?#

Note

The legacy Phoenix Tuner v1 is still available for use and is installed as part of the Phoenix installer.

Phoenix Tuner is the companion application allowing you to configure, analyze, update and control your device. Users may choose to use either Phoenix Tuner v1 (included as part of the Phoenix Installer) or Phoenix Tuner X (Android, Windows).

Phoenix Tuner X supports Android 8.0+ and Windows 10 (1903+) and Windows 11.

Important

While CTR Electronics supports both Phoenix Tuner v1 and Phoenix Tuner X, certain features such as device licensing and improved batch upgrading are only available in Phoenix Tuner X.

Tip

Many UI elements contain hover tooltips. That means the user can hover over them with their mouse for a text explanation of what they do.

Connecting Tuner#

Installed onto the robot controller (either manually or via a robot program) is the Phoenix Diagnostics Server. This program enables communication between Tuner X and the robot controller for managing and setting up devices.

Connecting to the Server#

A dropdown/textbox is available in the upper-left flyout menu.

Highlights the IP textbox in the left-hand flyout menu

By clicking the arrow, you can change between presets such as:

Driver Station – Retrieves the robot IP from the FRC Driver Station if launched
roboRIO USB – Defaults to 172.22.11.2 which is the roboRIO IP when connected via USB
localhost – Use for simulation or hardware-attached CANivore.

Alternatively, the user can manually enter the robot IP into the textbox.

Configuring SSH Credentials (non-FRC)#

When using a non-FRC robot controller (non-roboRIO), users must have their SSH credentials configured in Settings for general use.

SSH credential username and password is the 3rd and 4th textbox available to the user in settings

Temporary Diagnostics (FRC)#

Devices can be configured without a diagnostic server present. This can be useful if the roboRIO has been freshly imaged. Ensure that you are pointed at the roboRIO IP address (usually 10.TE.AM.2 where TE.AM is the team number) and then click the Run Temporary Diagnostic Server in Settings.

Temporary diagnostic server is the second button available to the user.

Changing Diagnostics Server Port (non-FRC)#

The target server port can be changed in the Tuner X Settings page, which is accessed from the flyout menu.

Important

The default port for diagnostic server is 1250. FRC users must not change this under any circumstance.

Port textbox is the second textbox available to the user.

Localhost Troubleshooting#

When Tuner X is first started after installation, it may request admin privileges to access the localhost network. If the user disallows admin access, diagnostic servers hosted on the local machine (simulation and hardware-attached CANivore) may not be visible in Tuner X. Users can manually grant this permission afterward by clicking the Grant Localhost Permissions in Settings.

Device List#

Card Layout

Grid Layout

Devices root page in Phoenix Tuner as a grid

The Devices page is the first page that is shown to the user upon launching the application. The Devices page by default shows a grid of cards, but can be changed to a flat grid view (similar to Phoenix Tuner v1) by clicking on the 4 grid square icon located in the top right corner (not available in Android Tuner X).

Card Colors#

The color of the device cards is helpful as a visual indicator of device state. The meaning of the card color is also shown as text underneath the device title.

Color	Description
Green	Device has latest firmware.
Purple	Device has unexpected firmware version.
Yellow	A new firmware version is available. Check the changelog to determine if the new version matters to your application
Red	Device has a duplicate ID.
Blue	Failed to retrieve list of available firmware.

Clipboard Options & Licensing#

Phoenix Tuner X provides icons at the bottom right of each card that will allow the user to copy to the clipboard the device details, configs and Self Test. This can be useful for support requests and additional debugging.

Devices that support CAN FD are shown via a CAN FD icon in the bottom right of the card.

Note

The CAN FD icon does not indicate that the device is currently on a CAN FD bus, merely that it supports CAN FD.

The other major icon in the bottom right of the device card is the licensing indicator. This showcases the licensing states and when clicked, will open the licensing dialog.

Batch Field Upgrade#

Phoenix Tuner X allows the user to batch field upgrade from the Devices page. The user can either select devices by their checkbox (in the top right corner of their respective card) or by selecting the checkmark icon in the top right.

Tip

Selecting a device using their checkbox and clicking the checkmark in the top right will select all devices of the same models

Showing batch selection option in the top right

Step 1 in the above image selects all devices of the same model (or all devices if no device is currently check-boxed).

Step 2 in the above image opens the field-upgrade dialog.

Once the upgrade dialog is opened, information detailing the device name, model, ID, and firmware version is presented. There is a Pro column that has a toggle. This toggle represents whether to upgrade to Pro or v5 firmware. If this toggle is disabled (as evident from being greyed out), then there is no available Pro firmware for that device (TalonSRX, legacy devices).

The user can begin the upgrade progress by selecting Update to latest or Select firmware…. The first option will upgrade all listed devices to their latest available firmware (v6 or v5 depending on the toggle state). The second option will open a popup allowing you to select a specific version or firmware file per model.

Tip

Generally, users should update their devices to the latest available firmware version. If manually selecting a CRF is important, the firmware files are available for download on our GitHub Repo.

Important

While the user can cancel firmware upgrading using the “X” button in the top-right, this will not cancel the current device in progress. It will finish upgrading the current device and will not upgrade subsequent devices. Typical Tuner X behavior will resume once the current device finishes flashing.

Device History#

Users can access a list of past devices connected to Tuner X and license them via the Device History page. This is accessible from the left-hand sidebar. This list is not automatically refreshed, but users can refresh it by pressing the refresh icon in the top-right of the page.

Licensing from Device History#

Users can activate a license for a disconnected device by clicking on the device in the Grid. Then, select the “PRO” icon at the bottom right of the device card.

From there, the user can activate a license for the device like normal. Once the device license has been activated, the user still needs to connect Tuner X to the robot to transfer the activated license to the device.

The “PRO” icon may be replaced with a greyed “LIC” icon in the following situations:

The device is on Phoenix 5 firmware and actively connected to Tuner X
The device is not a Phoenix 6 compatible device

Users who license an eligible Phoenix 6 device running Phoenix 5 firmware must update the device firmware to v6 compatible firmware to utilize licensed features.

Device Details#

The Device Details page can be accessed by clicking on the device card (or double clicking on the device row when in grid view). This view allows you to access detailed device actions such as:

Device Details (Name, ID, Firmware Version, Model, Serial No, etc.)
Blinking LEDs
Field Upgrading
Licensing Details (by clicking on the LIC/PRO icon)
Configs
Control
Self Tests
Plotting
Pigeon 2 Mount Calibration

Note

Plotting currently only works with Phoenix 5 devices.

Blinking#

All CTR Electronics devices can be blinked (rapidly flash the LEDs). This can be useful for handling whenever you have duplicate devices using the same ID on the CAN bus.

Verifying Device Details#

This screen highlights information such as (1) Device Name, (2) Device Model, (3) Firmware Version.

Tip

Clicking in the blank space outside the detail frames will bring the user back to the devices page.

Showcases Device Name, Device Model and firmware version placement.

Configuring Name & IDs#

All devices can have their Name (1) and ID (2) configured via their respective textbox. IDs are limited to the range of 0 to 62 (inclusive). After inputting the ID or name, press the Set button to save the changes to the device.

Field-Upgrade Firmware Version#

Tuner X has improved firmware upgrading functionality by automatically downloading and caching firmware. Upon initial Tuner X launch, the latest firmware for all devices will automatically be downloaded in the background (takes <10s on most internet connections). The individual device page allows you to select specific firmware versions for your device via the firmware dropdown. Batch firmware can also be completed via the batch field upgrade pop-up.

Important

Users should ensure they select Phoenix 6 firmware when using Phoenix 6 API, and Phoenix 5 firmware when using Phoenix 5 API. A single robot project may use both APIs simultaneously.

Users can switch between “Phoenix 6” and “Phoenix 5” by clicking on the toggle above the firmware dropdown.

Note

The toggle between Phoenix 6 and Phoenix 5 firmware only affects online field-upgrades.

Toggle switching between Phoenix 5 and Pro

Tuner Configs#

Tip

Devices can also be configured in code.

Configs can be viewed, modified, backed-up, restored, and factory-reset via the Configs tab in Phoenix Tuner X.

To apply a modified config, press the Apply Configs button on the bottom button bar.

Self Test Snapshot#

Self Test Snapshot is a diagnostic feature of all supported devices that will show the immediate state of the device. This is extremely useful for troubleshooting and ensuring the device is working properly. Phoenix 6 with Phoenix Tuner X improves upon Self Test by showing the information in clean tables, animations and detailed units.

Self Test also includes 3 buttons: Refresh, Blink/Clear Faults and Share to Support. Refresh will refresh the Self Test information, Blink/Clear faults` will blink the device and clear any faults on the device. Share to Support will open the default email client with an email to CTR Electronics support.

Viewing Status LEDs#

Phoenix 6 devices report status LEDs as an animated GIF in Phoenix Tuner X. This can be useful for diagnosing a device when it’s buried in a robot.

Highlight blinking LEDs in Phoenix Tuner X

Plotting#

Supported devices can have certain signals/sensor data plotted in real-time without any additional configuration. To get started, click on the Plot button in the top right navigation bar.

Tip

Plotting is supported in both Phoenix 5 and Phoenix 6.

At the top of this page is a list of supported values that can then be plotted. Click on the signal that you wish to plot. Then click Enable Plot on the left.

Adjusting Plotting Time Period#

Plotting time period (the time frame that points are recorded) can be adjusted using the Time Period textbox.

Exporting Data#

Plots can be exported into csv format for viewing in an external analysis tool. Click on the Export as CSV button.

Plot Appearance & Behavior#

Important

Scatter points may dramatically affect Tuner X performance.

Plotting supports zoom and panning via the mouse and scroll wheel (or via gestures on Android). The point appearance can also be adjusted between “Spline” and “Scatter”.

Points as shown when scatter is selected.

Pigeon 2.0 Calibration#

It is recommended that calibration is performed once the Pigeon 2.0 has been mounted to the robot. Calibration will calculate the optimal offsets to apply to ensure that Pose, Pitch and Yaw is 0 when the robot is considered “flat”. Users can access the calibration menu by clicking on the Pigeon 2.0 in Devices and clicking Calibration in the top right.

Pigeon calibration button is located to the top right of tuner device view

Read through the on-screen instructions and click Begin Mount Calibration.

Pigeon calibration page, calibration button is located on the right side

TalonFX#

The Falcon 500 powered by Talon FX is a brushless motor with an integrated motor controller and high-resolution encoder, custom designed specifically for the FIRST Robotics Competition, through a collaboration between Cross the Road Electronics and VEX Robotics.

Store Page

CAD, Firmware and purchase instructions.

Hardware User Manual

Wiring and mount instructions in PDF format.

Actuator Limits#

CTR Electronics actuators, such as the TalonFX, support various kinds of hardware and software limits.

Documentation on retrieving and configuring limits can be found here.

Limit Switches#

CTR Electronics supported actuators have limit features that will automatically neutral the actuator output (set voltage to 0) if a limit switch is activated. By default, limits are set to “normally open”. This means that the switch needs to be explicitly closed (or grounded) for the actuator output to be set to neutral.

When the limit switch is closed (connected to ground), the actuator will disable and the pattern will move toward the forward/reverse limit pin (red blink pattern will move toward the forward limit pin when the forward limit is closed, and vice-versa).

Tip

For more information on limit switch wiring, consult the TalonFX User’s Guide.

Status Light Reference#

Status LEDs located in central part of the motor

LED State	Description
Alternating Off/Orange	Talon FX is disabled. Robot controller is missing on the bus or the diagnostic server is not installed.
Simultaneous Off/Orange	Talon FX is disabled. Phoenix is running in Robot Controller.
Alternating Red/Green	Talon FX is not licensed. Please license device in Phoenix Tuner.
Off/Slow Red	CAN/PWM is not detected.
Red/Orange	Damaged Hardware
Off/Red	Limit Switch or Soft Limit triggered.
Green/Orange	Device is in bootloader.

Pigeon 2.0#

Pigeon 2.0 is the next evolution in the family of Pigeon IMUs.

With no on-boot calibration or temperature calibration required and dramatic improvement to drift, the Pigeon is the easiest IMU to use yet.

Pigeon 2 Troubleshooting#

A functional limitation was discovered in Pigeon 2s manufactured in September of 2022. When used on a CANivore (CAN FD) Bus, the Pigeon 2 may not transmit CAN FD frames correctly. As a result, you may find that all CAN device LEDs go red when the Pigeon 2 is in-circuit and powered.

A firmware fix has been published, to update the firmware of an affected Pigeon 2, one of the below options can be used.

Option 1: Workaround with Tuner X#

Note

If you do not see the below option, then Tuner X is likely older than version 2023.1.5.0.

A new section in Tuner X Settings labeled Pigeon 2 Workaround has been added. When the Execute Pigeon 2 workaround button is pressed, all CANivores will enter a special mode that allows them to see the offending Pigeon 2s. This mode is reverted when the CANivore is power cycled.

Once the workaround has been applied, the device will show up in the Devices menu and the LED should be alternating green/orange. Field-upgrade the firmware version and power cycle the CANivore.

Option 2: Connect to the roboRIO Bus#

Connect the Pigeon 2 to the roboRIO CAN Bus and field-upgrade the firmware version.

Note

We recommend power cycling Pigeon after moving CAN bus leads from CANivore to roboRIO CAN bus to ensure a clean transition.

Store Page

CAD, Firmware and purchase instructions.

Hardware User Manual

Wiring and mount instructions in PDF format.

Status Light Reference#

LED Color	Blink Pattern	Description
Off		Pigeon 2.0 is not powered.
Yellow/Green	Only a single LED will blink with this pattern.	Device is in boot-loader, most likely because firmware upgrading has failed. Inspect CAN bus wiring and retry firmware upgrading. If device has valid firmware, turn device off, wait 10 seconds, and turn device back on.
Red/Green	Alternating Red/Green	Device is not licensed. License device in Phoenix Tuner.
Red/Yellow	LEDs are never off - one of the two colors are always illuminated	Hardware is damaged
Red Blink		Check CAN bus health and connection to the Pigeon 2.0
Yellow	Alternate Blinking	CAN bus detected but robot controller is not detected (or Pigeon 2.0 is not referenced in code)
Yellow	Simultaneous Blinking	CAN bus detected, robot is disabled.
Green Blink		CAN bus detected. Robot is enabled

Mount Calibration#

It’s recommended to perform a mount calibration when placement of the Pigeon 2.0 has been finalized. This can be done via the Calibration page in Tuner X.

CANcoder#

Important

As of late August 2022, there are multiple hardware versions of CANcoder available. This is due to the ongoing worldwide chip shortage causing CTR Electronics to replace the original processor with a substitute. This new version of CANcoder requires a different firmware, but is otherwise functionally identical to the original. Details on checking the version can be found in the device details section.

The CANcoder is the next evolution in the line of CTRE magnetic encoder products. As its name implies, this product is a rotary magnetic encoder that communicates over the CAN bus. Supporting CAN FD and CAN 2.0, this product provides the same position and velocity with the same resolutions you’ve come to expect from the SRX Magnetic Encoder.

Store Page

CAD, Firmware and purchase instructions.

Hardware User Manual

Wiring and mount instructions in PDF format.

Status Light Reference#

Note

Users wishing to test magnet placement must wait 8 seconds after boot for the LEDs to blink the magnet placement status.

LED Color	Led Brightness	CAN bus Detection	Magnet Field Strength	Description
Off				CANcoder is not powered/plugged in. Check power cabling to the CANcoder.
Yellow/Green	Bright			Device is in boot-loader, most likely because firmware upgrading has failed. Inspect CAN bus wiring and retry firmware upgrading. If device has valid firmware, turn device off, wait 10 seconds, and turn device back on.
Slow Red Blink	Bright	CAN bus has been lost.		Check CAN bus health and connection to the CANcoder.
Red/Green	Bright			Device is not licensed. Please license device in Phoenix Tuner.

Rapid Red Blink	Dim	CAN bus never detected since boot	<25mT or >135mT	Magnet is out of range
Rapid Yellow Blink	Dim	CAN bus never detected since boot	25-45mT or 75-136mT	Magnet in range with slightly reduced accuracy
Rapid Green Blink	Dim	CAN bus never detected since boot	Magnet in range	Magnet in range

Rapid Red Blink	Bright	CAN bus present	<25mT or >135mT	Magnet is out of range
Rapid Yellow Blink	Bright	CAN bus present	25-45mT or 75-136mT	Magnet in range with slightly reduced accuracy
Rapid Green Blink	Bright	CAN bus present	Magnet in range	Magnet in range

Magnet Placement#

Using the CANcoder User’s Guide, verify that magnet placement is correct for the CANcoder.

Verifying Sensor Direction#

CANcoder sensor direction can be configured via the Config page in Phoenix Tuner X.

CANivore Intro#

The CANivore is a multipurpose USB-to-CAN FD device. The CANivore:

Adds a secondary CAN FD bus to the roboRIO
- CAN FD improves upon CAN with increased device bandwidth and transfer speed.
Allows the control of CTR Electronics devices on non-roboRIO platforms.

Important

Details on licensing your CANivore is available on the licensing page.

Initial Setup

Setting up a CANivore for robot projects and desktop development.

API Usage

Using the CANivore with devices in API.

Hardware-Attached Simulation

Using a CANivore with hardware devices in a desktop environment.

Advanced Configuration

Advanced configuration options for the CANivore.

CANivore Setup#

Supported Systems#

Currently, the following systems are supported for CANivore development:

NI roboRIO
Windows 10/11 x86-64
Linux x86-64 (desktop)
- Ubuntu 22.04 or newer
- Debian Bullseye or newer
Linux ARM32 and ARM64 (Raspberry Pi, NVIDIA Jetson)
- Ubuntu 20.04 or newer
- Debian Bullseye or newer

Note

Custom bit rates and CAN 2.0 are not supported at this time. The parameters passed into SocketCAN are not applied by the firmware.

roboRIO#

Note

Phoenix Tuner X requires a 2023 roboRIO image or newer to configure the CANivore.

No additional steps are required. The roboRIO comes with the canivore-usb kernel module pre-installed.

Linux (non-FRC)#

On non-FRC Linux systems, the canivore-usb kernel module must be installed to add SocketCAN support for the CANivore. The kernel module is distributed through our APT repository. Begin with adding the repository to your APT sources.

YEAR=<year>
sudo curl -s --compressed -o /usr/share/keyrings/ctr-pubkey.gpg "https://deb.ctr-electronics.com/ctr-pubkey.gpg"
sudo curl -s --compressed -o /etc/apt/sources.list.d/ctr${YEAR}.list "https://deb.ctr-electronics.com/ctr${YEAR}.list"

Note

<year> should be replaced with the year of Phoenix 6 software for which you have purchased licenses.

After adding the sources, the kernel module can be installed and updated using the following:

Important

Users on a Raspberry Pi OS based platform must install the kernel headers before running the below install script. Headers can be installed by running sudo apt install raspberrypi-kernel-headers.

sudo apt update
sudo apt install canivore-usb

Tip

To get a robot application up and running quickly, check out our non-FRC Linux example.

Raspberry Pi 4 Errata#

On a Raspberry Pi 4 or newer, the latest 32-bit Raspberry Pi OS image will default to using the 64-bit kernel while still using 32-bit APT packages. As a result, our canivore-usb kernel module will fail to install.

There are two options to work around this issue:

(Recommended) Use the 64-bit Raspberry Pi OS. This allows programs to use all available RAM and improves overall system performance and stability.
Add arm_64bit=0 to /boot/config.txt and reboot. This forces the Raspberry Pi to use the 32-bit kernel. Note that programs will be limited to using 3 GB of RAM, and system performance may be impacted.

Warning

Do not add arm_64bit=0 to /boot/config.txt when using the 64-bit Raspberry Pi OS. Attempting to do so may cause the Pi to be unable to boot.

Viewing Attached CANivores#

Attached CANivores can be viewed in Phoenix Tuner X by selecting the CANivores page from the left-hand sidebar. You can specify the target system in the Target IP or Team # text box.

Showing where the CANivores page is in the left-hand sidebar

Note

The Phoenix Diagnostic Server must be running on the target system to use the CANivores page.

Tip

If you are connecting to CANivores on your local Windows machine, you can enable the CANivore USB toggle and set the target IP to localhost. This runs a diagnostic server within Tuner X so you do not need to run a robot project to communicate with CANivores.

Field Upgrading CANivores#

A CANivore can be field updated using Phoenix Tuner X.

Click or tap on the listed CANivore card:

The CANivore can then be field upgraded via the dropdown or by manually selected a file:

Phoenix Tuner X also allows the user to batch field upgrade CANivores from the list of CANivores in the same manner as batch field upgrading devices.

Renaming CANivores#

CANivores can be given custom names for use within a robot program. This can be configured through Phoenix Tuner X on the specified device card.

CANivore API#

All device constructors have an overload that takes a string CAN bus identifier. This identifier can be rio for the native roboRIO CAN bus, * to select the first available CANivore, or a CANivore’s name or serial number. On non-FRC Linux systems, this string can also be a SocketCAN interface.

Note

If there are multiple CANivores with the same name, the system will use the first CANivore found.

If no CAN bus string is passed into the constructor, or the CAN bus string is empty, the behavior is platform-dependent:

roboRIO: use the roboRIO native CAN bus
Windows: use the first CANivore found
non-FRC Linux: use SocketCAN interface can0

Java

TalonFX fx_default = new TalonFX(0); // On roboRIO, this constructs a TalonFX on the RIO native CAN bus
TalonFX fx_rio = new TalonFX(1, "rio"); // This also constructs a TalonFX on the RIO native CAN bus
TalonFX fx_drivebase = new TalonFX(0, "Drivebase"); // This constructs a TalonFX on the CANivore bus named "Drivebase"
CANcoder cc_elevator = new CANcoder(0, "Elevator"); // This constructs a CANcoder on the CANivore bus named "Elevator"

C++ (Header)

hardware::TalonFX fx_default{0}; // On roboRIO, this constructs a TalonFX on the RIO native CAN bus
hardware::TalonFX fx_rio{1, "rio"}; // This also constructs a TalonFX on the RIO native CAN bus
hardware::TalonFX fx_drivebase{0, "Drivebase"}; // This constructs a TalonFX on the CANivore bus named "Drivebase"
hardware::CANcoder cc_elevator{0, "Elevator"}; // This constructs a CANcoder on the CANivore bus named "Elevator"

CANivore Status Prints#

When working with CANivore CAN buses in a robot program, Phoenix prints some messages to report the state of the CANivore connection. These messages can be useful to debug connection issues (bad USB vs bad CAN) or report bugs to CTR Electronics.

Connection Messages#
Message	Connection Status
CANbus Failed to Connect	Could not connect to a CANivore with the given name or serial number
CANbus Connected	Successfully found and connected to the CANivore with the given name or serial number
CANbus Disconnected	Detected that a CANivore USB device has been disconnected

CANivore Bring-up Messages (Linux only)#
Message	Bring-up Status
CANbus Failed Bring-up	Found and connected to the CANivore, but could not configure the device or start the network
CANbus Successfully Started	Successfully configured the CANivore and started the network

Network State Messages#
Message	Network State
CANbus Network Down	Linux: The SocketCAN network has been deactivated, USB-to-CAN activity has stopped Windows: Could not open the communication channels for USB-to-CAN traffic
CANbus Network Up	Linux: The SocketCAN network has been activated, USB-to-CAN activity has resumed Windows: Successfully opened the communication channels for USB-to-CAN traffic

Hardware-Attached Simulation#

CANivore supports hardware-attached simulation when used in an FRC robot program. This allows a CANivore to be used with real devices on supported host operating systems. The below video showcases controlling a real Falcon 500 in a robot program using hardware-attached simulation.

To utilize hardware-attached simulation, ensure the CANivore is connected directly via USB to the machine running the simulation. All devices on the CANivore CAN Bus should be independently powered, as the CANivore does not provide power. In the robot program, the CANivore name or * must be specified in the device constructor.

Important

Any motors/actuators that have been connected to a roboRIO CAN Bus at any time must be factory defaulted due to them being FRC Locked. Factory defaulting can be done in Tuner X and should be done when the CANivore is not connected to a roboRIO.

Java

TalonFX m_motor = new TalonFX(0, "mycanivore");

C++

hardware::TalonFX m_motor{0, "mycanivore"};

In VS Code, select the 3 dots in the top-right, then select Hardware Sim Robot Code

Location of hardware attached simulation

A message in the console should appear that the CAN Bus is connected.

********** Robot program startup complete **********
[phoenix] CANbus Connected: uno (WinUSB, 2B189E633353385320202034383803FF)
[phoenix] CANbus Network Up: uno (WinUSB, 2B189E633353385320202034383803FF)
[phoenix] Library initialization is complete.

Advanced Configuration#

The CANivore provides additional configuration options for advanced users.

CAN Bus Termination#

The CANivore has a 120 \(\Omega\) programmable resister for terminating the CAN bus. The resistor can be configured using the CAN Bus Termination toggle in the CANivore device card in Phoenix Tuner X.

Warning

A CAN bus requires two termination resistors, one at each extreme end. If only one is present, communication over CAN may fail.

CAN bus termination is the second toggle in the CANivore device card

caniv - CANivore CLI#

caniv is a Command-line Interface (CLI) to interact with CANivores outside of Phoenix Tuner X.

Note

Unlike the CANivores page in Phoenix Tuner X, caniv does not require a running Phoenix Diagnostic Server.

On Linux systems (including the roboRIO), caniv can be found at /usr/local/bin. On Windows systems, the program is in the Phoenix Tuner X application cache directory, which can be opened by opening the Diagnostic Log page and clicking the left folder icon in the top right:

Opening the Tuner X application cache folder

To view a list of available commands, run caniv either with no parameters or with --help.

Development Blog#

Welcome to the development blog. Here, we will highlight various features of CTR Electronics devices and how they can be utilized in specific applications.

Note

This list may move in the future.

Latency and Frequency#

Authored by Cory

A common discussion with CAN-based sensors and actuators is how latency and update frequency affect robot performance. This devblog is meant to expand what these aspects are and how users can mitigate or eliminate them with Phoenix 6/Pro.

Frequency#

Signal frequency largely affects two aspects for robots:

Closed loop control
Odometry

Closed loop control is pretty clear, the slower the frequency, the greater the time gaps and the more you have to dampen a closed loop controller to keep it smooth. This becomes more important the less inertia your system has, such as with a swerve drive azimuth. At the inertia of a full robot, this becomes less important, as the robot can’t change its own heading fast enough for the lower frequency to have much of an impact.

Odometry is a little less clear, but the gist is that odometry itself is generally an integration problem. If your data is coming in at a lower frequency, the integration isn’t as accurate, and so you accrue drift and error. This gets worse over time, which is why absolute odometry solutions such as april tag pose are so important at the high level to correct for it.

Latency#

Latency itself isn’t so much an issue, but nondeterministic latency can be. If you aren’t getting data at a steady rate, it can negatively affect the odometry, as the time aspect of the integration problem is no longer constant. You can correct for this with latency compensation if you have the option to, but even that’s not a perfect solution as the latency corrected value may not be exactly correct to the real value at that point in time (although it’s certainly better than nothing).

Solutions#

We (CTR Electronics) recognized these problems in general and wanted to solve them, which is why each of these problems are solved in the new Phoenix 6/Pro library and with CANivore.

Fused CANcoder (Pro): By fusing in the CANcoder’s position into the Talon FX’s internal position, users ensure the position is always absolute while maintaining 1000hz update frequency and 0 latency for closed loop operations. This feature is improved when used with CANivore, as the CANcoder’s position can be latency-compensated and fused even when the mechanism is moving.
Time Synchronization (Pro & CANivore): The CANivore provides the ability for Pro devices to synchronize to a common clock, which allows all the devices to sample data at the same time and publish data at the same time. This makes latency of data between devices minimal, and when used with our synchronize API keeps total latency low.
Synchronous API (v6): The synchronous API allows users to wait for data to arrive. By waiting for all the key data to arrive, the overall latency is reduced and users can update their robot’s data as soon as new data is available.
Time Stamps (v6): Every data is timestamped so users can perform latency compensation. The timestamp information is improved if used with a CANivore, as the CANivore timestamps the data once it arrives over the wire, providing a more accurate timestamp compared to when the RIO does the timestamping.
Improved bus utilization (v6): The improved bus utilization with v6 and further improvement with CANivore allow you to pretty easily increase the frequency of your key signals. We think it’s pretty achievable to get 200hz update frequencies (5ms periods) under a full robot.

Every component outlined here is used in our SwerveDriveExample. If you’re interested in how to do it for yourself, I’d recommend looking at it and doing something similar.

Tuner and an evolution in configuration#

Authored by Dalton

Since the introduction of the CTRE Toolsuite (pre-2018), we at CTR have strived to provide intuitive means of configuring and utilizing our products. In 2018, we launched Phoenix Tuner (now lovingly referred to as Tuner v1). Tuner v1 introduced features like: batch firmware upgrading like devices, diagnostic server deployment, self tests, plotting and control.

With Tuner, and by extension diagnostics, we have several primary objectives:

Ease of debugging (exposed via self test).
Seamless setup experience.
Support and integrate our extension feature-set.

Tuner v1 was and is great, but we wanted to do more. In the 2023 season, we introduced Tuner X.

Introducing Tuner X#

The goal we had with Tuner X development was to refine and enhance the existing Tuner v1 feature set. We introduced Android support, improved batch upgrading, improved highlighting of duplicate devices, automatic firmware downloads (no more downloading CRFs!), improved self test and licensing support.

With Tuner X, users can:

Configure their device’s name & ID
Blink a device, which is useful for identifying where the device is on the robot.
Firmware update all devices to the latest version available (no more CRF downloads).
Control individual motors with their Android phone, or on Windows.
Plot various signals such as velocity, position and yaw.
Self test their v6 device, which provides a marked up self test of the device.

Important

Tuner X does not require v6 and can be used with v5 flashed devices.

For a full list of features, check out the v6 documentation.

Introducing a new iteration of Tuner X#

Some of you may have noticed that your version of Tuner X has changed recently. We’ve been working on several key improvements to the application that should dramatically improve the user experience. While this blog will highlight some of those, it’s best to just try out the new Tuner yourself.

Note

Feedback is welcome and can be provided by emailing feedback@ctr-electronics.com.

Improved connection diagnostics#

Tuner requires a running diagnostic server to work. Typically, this is installed through a robot program utilizing one of our devices. Alternatively, this program is temporarily run using a button in Settings. We’ve improved the disconnection status card to contain information about the ping of the target and diagnostic state of the device.

This 3 step check looks for the following:

Ping of the target.
Is diagnostics (or a robot program with diagnostics) running?
Are there any devices reported?

To summarize, if a user is not seeing devices in Tuner but checks 1 and 2 are good, then the next recommendation is to check the LED status of the device. We have an extensive list of status LEDs that indicate if the device is detected on a CAN bus, or other problems. This list can be found on the corresponding device page in the docs. For example, look at the CANcoder LED table.

Redesigned device overview#

The device overview page has been redesigned to improve usability of plot, control and configuration. It’s never been easier to tune your closed-loop gains directly in Tuner!

Bug squashing and usability improvements#

This list is by no means exhaustive, but provides a good idea of the changes between 2023.X and 2024 versions of Tuner X.

Firmware selection now has a dropdown for year, allowing you to flash older year firmware
Dramatically improved startup and navigation performance
Dramatically improved plotting performance
Dramatically improved commands timing out on Android Tuner
Enable/Disable button colors have been adjusted to be more clear
Fixed “connection blipping” on Android Tuner
Fixed control sometimes stuttering and causing the device to disable
Fixed licensing sometimes fail to load on Android Tuner
Fixed SSH credentials popup not appearing sometimes
Fixed lag when entering into various entries
Fixed memory leak when plotting for long periods of time
Fixed situation where the application would shutdown uncleanly and lose settings
Fixed various clipping of icons, text and labels
Fixed issue where CANivore USB toggle would be unable to enable or disable
Fixed firmware flashing on Raspberry Pi
Fixed temporary diagnostic deployment on non-RIO platforms
Slows down CANivore polling, which improves Rio CPU performance when Tuner is open

What’s next?#

We have a couple of exciting improvements to Tuner on our radar, keep an eye out on our changelog. Tuner X can be downloaded via the Microsoft Store and the Google Play Store.

Troubleshooting#

CAN Bus Troubleshooting#

There are typically two failure modes that must be resolved:

There are same-model devices on the bus with the same device ID (devices have a default device ID of ‘0’).
CAN bus is not wired correctly or robustly

During hardware validation, you will likely have to isolate each device to assign a unique device ID.

Note

CTRE software has the ability to resolve device ID conflicts without device isolation, and CAN bus is capable of reporting the health of the CAN bus (see Driver Station lightening tab). However, the problem is when both root-causes are occurring at the same time, this can confuse students who have no experience with CAN bus systems.

Note

Many teams will pre-assign and update devices (Talon SRXs for example) long before the robot takes form. This is also a great task for new students who need to start learning the control system (with the appropriate mentor oversight to ensure hardware does not get damaged).

Identifying Duplicate IDs#

Tip

Label the devices appropriately so there is no guessing which device ID is what. Don’t have a label maker? Use tape and/or Sharpie (sharpie marks can be removed with alcohol).

Phoenix Tuner X will report when there are multiple devices of the same model with the same ID. This is shown when the device card is RED and there is a message in the middle of the device card. Users seeing this should iteratively reassign IDs on the device(s).

Check your wiring#

Specific wiring instructions can be found in the user manual of each product, but there are common steps that must be followed for all devices:

If connectors are used for CAN bus, tug-test each individual crimped wire one at a time. Bad crimps/connection points are the most common cause of intermittent connection issues.
Confirm red and black are not flipped.
Confirm battery voltage is adequate (through Driver Station or through voltmeter).
Manually inspect and confirm that green-connects-to-green and yellow-connects-to-yellow at every connection point. Flipping/mixing green and yellow is a common failure point during hardware bring up.
Confirm breakers are installed in the PDP where appropriate.
Measure resistance between CANH and CANL when system is not powered (should measure ~60Ω). If the measurement is 120Ω, then confirm both RIO and PDP are in circuit, and PDP jumper is in the correct location.

LEDs are red - now what?#

We need to rule out same-ID versus bad-bus-wiring.

There are two approaches:

Approach 1 will help troubleshoot bad wiring and common IDs.
Approach 2 will only be effective in troubleshooting common IDs, but this method is noteworthy because it is simple/quick (no wiring changes, just pull breakers).

The specific instructions for changing device ID are in the next section. Review this if needed.

Approach 1 (best)#

Physically connect CAN bus from roboRIO to one device only. Circumvent your wiring if need be.
Power boot robot/bench setup.
Open Phoenix Tuner X and wait for connection (roboRIO may take ~30 seconds to boot)
Open the Devices page
Confirm that CAN device appears
Use Tuner X to change the device ID
Label the new ID on the physical device
Repeat this procedure for every device, one at a time

If you find a particular device where communication is not possible, scrutinize device’s power and CAN connection to the system. Make the test setup so simple that the only failure mode possible is within the device itself.

Note

Typically, there must be two 120-\(\Omega\) termination resistors at each end of the bus. CTR Electronics integrates termination resistors into the PDP and the CANivore. The roboRIO also has an integrated termination resistor. During bring-up, if you keep your harness short (such as the CAN pigtail leads from a single TalonFX) then a single resistor is adequate for testing purposes.

Approach 2 (easier)#

Leave CAN bus wiring as is
Pull breakers and PCM fuse from PDP
Disconnect CAN bus pigtail from PDP
Pick the first device to power up and restore breaker/fuse/pigtail so that only this CAN device is powered
Power boot robot/bench setup
Open Phoenix Tuner X and wait for connection (roboRIO may take ~30 seconds to boot)
Open the Devices page
Confirm that CAN device appears
If device does not appear, scrutinize device’s power and CAN connection to the system
Use Tuner X to change the device ID
Label the new ID on the physical device
Repeat this procedure for every device

If you find a particular device or section of devices where communication is not possible, then the CAN bus wiring needs to be re-inspected. Remember to “flick” / “shake” / “jostle” the CAN wiring in various sections to attempt to reproduce red LED blips. This is a sure sign of loose contact points.

If you are able to detect and change device ID on your devices individually, begin piecing your CAN bus together. Start with either roboRIO <—-> device <—> PDP, or CANivore <—-> device <—> 120 \(\Omega\) resistor, to ensure termination exists at both ends. Then introduce the remaining devices until a failure is observed or until all devices are in-circuit.

If introducing a new device creates a failure symptom, scrutinize that device by replacing it, inspecting common wires, and inspecting power.

At the end of this section, all devices should appear (notwithstanding the above notes) and device LEDs should not be red. TalonFX and Pigeon2 typically blink orange when they are healthy and not controlled, and CANcoder rapid-blinks brightly. PDP may be orange or green depending on its sticky faults.

Support#

CTR Electronics prides itself on excellent customer service. Our contact information can be found on our website.

Phoenix 6 Documentation#

Installing Phoenix 6#

API Installation#

System Requirements#

Offline#

Online#

Tuner X Installation#

Running the Diagnostic Server#

1: Deploying a Robot Program#

2: Running Temporary Diagnostic Server#

Configuring your Device#

New to Phoenix#

Phoenix 6#

Comprehensive API#

Canonical Units#

Improved Device Control#

Enhanced Support for CAN FD#

New Tuner X Self Tests#

Free High-Fidelity Simulation#

Continuous Wrap Mode#

Phoenix Pro#

Field Oriented Control (FOC)#

Time Base Synchronization#

Fused CANcoder#

Feature Breakdown#

API Migration#

Configuration#

Applying Configs#

Factory Defaulting Configs#

Retrieving Configs#

Status Signals#

Using Status Signals#

Changing Update Frequency (Status Frame Period)#

Common Signals#

General Signals#

Talon FX Signals#

CANcoder Signals#

Pigeon 2 Signals#

Control Requests#

Using Control Requests#

Follower Motors#

Changing Update Frequency (Control Frame Period)#

Control Types#

Closed-Loop Control#

Closed-Loop Setpoints#

Closed-Loop Gains#

Position without Voltage Comp#

Position with Voltage Comp#

Velocity without Voltage Comp#

Velocity with Voltage Comp#

Using Closed-Loop Control#

Motion Magic®#

Motion Profiling#

Feature Replacements#

Motor Invert#

Neutral Mode#

Nominal Output#

Sensor Phase#

Sensor Initialization Strategy#

Clear Position on Limit#

Velocity Measurement Period/Window#

Integral Zone and Max Integral Accumulator#

Features to Be Implemented#

Features Omitted#

CAN Bus Utilization#

Device Licensing#

Purchasing a License#

Activating a License#

Activating a License without a Robot#

Verifying Activation State#

Troubleshooting#

Phoenix Tuner X#

What is Phoenix Tuner X?#

Connecting Tuner#

Connecting to the Server#

Configuring SSH Credentials (non-FRC)#

Temporary Diagnostics (FRC)#

Changing Diagnostics Server Port (non-FRC)#

Localhost Troubleshooting#

Device List#

Comprehensive API #

Enhanced Support for CAN FD #

New Tuner X Self Tests #

Free High-Fidelity Simulation #

Continuous Wrap Mode #

`StatusSignal`#

`SignalMeasurement`#