1. Manuals
  2. Brands
  3. CTR Electronics Manuals
  4. Motherboard
  5. Phoenix Pro
  6. Manual

CTR Electronics Phoenix Pro Manual

Hide thumbs
Table of Contents

Advertisement

Quick Links

Download this manual
Phoenix Pro
CTR Electronics
May 19, 2023

Advertisement

Table of Contents
loading
Need help?

Need help?

Do you have a question about the Phoenix Pro and is the answer not in the manual?

Questions and answers

Summary of Contents for CTR Electronics Phoenix Pro

  • Page 1 Phoenix Pro CTR Electronics May 19, 2023...
  • Page 3 Intro Why Phoenix Pro? Installing Phoenix Pro Configuring your Device Device Licensing Phoenix Tuner X TalonFX Pigeon 2.0 CANcoder API Usage 10 Simulation 11 WPILib Integration 12 Examples 13 CANivore Intro 14 CANivore Setup 15 CANivore API 16 Hardware-Attached Simulation...
  • Page 5 CTR Electronics Phoenix Pro Devices. Phoenix Pro represents a complete rewrite of the software framework over the existing Phoenix 5 framework. With Phoenix Pro, users have access to many new features that expand the control the user has over their devices.
  • Page 6 Phoenix Pro...
  • Page 7 Why Phoenix Pro? Phoenix Pro currently offers the following features and will further expand. 1.1 Comprehensive API • Device signal getters return a StatusSignalValue object, expanding the functionality of status signals. • Control devices with an extensive list of flexible, strongly-typed control request objects.
  • Page 8 1.8 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. • Try Phoenix Pro before you buy! Chapter 1. Why Phoenix Pro?

  • Page 9: System Requirements

    Installing Phoenix Pro Installation of Phoenix Pro is comprised of a few steps • Installing API • Installing Tuner • Updating Device Firmware • Device Licensing 2.1 API Installation Phoenix Pro currently supports Java and C++ for development. 2.1.1 System Requirements The following targets are supported: •...
  • Page 10 3. Apply the vendordep via WPILib VSCode Adding Offline Libraries 2.1.3 Online FRC (Pro Only) Important: This vendordep is for robot projects that are only using Phoenix Pro licensed devices. Paste the following URL in WPILib VS Code Install New Libraries (Online) •...
  • Page 11 -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 Pro software for which you have purchased licenses. After adding the sources, Phoenix Pro can be installed and updated using the following: sudo apt update...
  • Page 12 Phoenix Pro Chapter 2. Installing Phoenix Pro...

  • Page 13: 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 Pro API. Please visit the relevant Tuner pages on how to complete these steps.
  • Page 14 Phoenix Pro Chapter 3. Configuring your Device...

  • Page 15: Device Licensing

    All license activation and verification features are only available in Phoenix Tuner X. Phoenix Tuner v1 does not support licensing actions. 4.1 Purchasing a License Licenses can be purchased in the licensing section on the CTR Electronics store. Click here to purchase a license.
  • Page 16 Phoenix Pro 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. Chapter 4. Device Licensing...
  • Page 17 Phoenix Pro 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.
  • Page 18 Phoenix Pro 4.2.1 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. 4.3 Verifying Activation State An icon displaying the license state of your device is located in the bottom right of the device card.

  • Page 19: Troubleshooting

    Phoenix Pro State Image Description Licensed Device is licensed for the current version of Phoenix Pro API. CANivore con- CANivore contains at least one bus license, which it will use tains Licenses to remote-license all compliant CAN devices. Licensing Device is licensed and there was an error communicating Error license state.
  • Page 20 Phoenix Pro Chapter 4. Device Licensing...
  • Page 21 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.
  • Page 22 Phoenix Pro Connecting to the Server A dropdown/textbox is available in the upper-left 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 •...
  • Page 23 Phoenix Pro 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.
  • Page 24 Phoenix Pro 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.
  • Page 25 Phoenix Pro 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.

  • Page 26: Device List

    Phoenix Pro 5.1.2 Device List Chapter 5. Phoenix Tuner X...
  • Page 27 Phoenix Pro Card Layout 5.1. What is Phoenix Tuner X?
  • Page 28 Phoenix Pro Grid Layout 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).
  • Page 29 Phoenix Pro 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.
  • Page 30 Phoenix Pro 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.
  • Page 31 Phoenix Pro 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 (Pro 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.
  • Page 32 Phoenix Pro 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.

  • Page 33: Device History

    Phoenix Pro 5.1.3 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.

  • Page 34: Device Details

    Phoenix Pro From there, the user can activate a license for the device like normal. Once the device li- cense has been activated, the user still needs to connect Tuner X to the robot to transfer the activated license to the device.
  • Page 35 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.
  • Page 36 Phoenix Pro 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. Chapter 5. Phoenix Tuner X...
  • Page 37 Batch firmware can also be completed via the batch field upgrade pop-up. Important: Users should ensure they select Phoenix Pro firmware when using Phoenix Pro API, and Phoenix 5 firmware when using Phoenix 5 API. A single robot project may use both APIs simultaneously.
  • Page 38 Phoenix Pro Users can switch between “Phoenix Pro” and “Phoenix 5” by clicking on the toggle above the firmware dropdown. Note: The toggle between Phoenix Pro and Phoenix 5 firmware only affects online field- upgrades. Chapter 5. Phoenix Tuner X...
  • Page 39 Phoenix Pro 5.1.5 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. 5.1. What is Phoenix Tuner X?
  • Page 40 Phoenix Pro To apply a modified config, press the Apply Configs button on the bottom button bar. Chapter 5. Phoenix Tuner X...
  • Page 41 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 Pro with Phoenix Tuner X improves upon Self Test by showing the information in clean tables, animations and detailed units.
  • Page 42 Phoenix Pro Viewing Status LEDs Phoenix Pro 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. 5.1.7 Plotting Supported devices can have certain signals/sensor data plotted in real-time without any ad- ditional configuration.
  • Page 43 Phoenix Pro 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. 5.1. What is Phoenix Tuner X?
  • Page 44 Phoenix Pro Adjusting Plotting Time Period Plotting time period (the time frame that points are recorded) can be adjusted using the Time Period textbox. Chapter 5. Phoenix Tuner X...
  • Page 45 Phoenix Pro 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 An- droid).
  • Page 46 Phoenix Pro 5.1.8 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.
  • Page 47 Phoenix Pro Read through the on-screen instructions and click Begin Mount Calibration. 5.1. What is Phoenix Tuner X?
  • Page 48 Phoenix Pro Chapter 5. Phoenix Tuner X...

  • Page 49: Limit Switches

    Store Page CAD, Firmware and purchase instructions. Hardware User Manual Wiring and mount instructions in PDF format. 6.1 Actuator Limits CTR Electronics actuators, such as the TalonFX, support various kinds of hardware and soft- ware limits. Documentation on retrieving and configuring limits can be found here.
  • Page 50 Phoenix Pro 6.2 Status Light Reference LED State Description Alternating Talon FX is disabled. Robot controller is missing on the bus or the Off/Orange diagnostic server is not installed. Simultaneous Talon FX is disabled. Phoenix is running in Robot Controller.
  • Page 51 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. 7.1 Pigeon 2 Troubleshooting A functional limitation was discovered in Pigeon 2s manufactured in September of 2022.
  • Page 52 Phoenix Pro 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. 7.1.2 Option 2: Connect to the roboRIO Bus...

  • Page 53: Mount Calibration

    Phoenix Pro Blink Pattern Description Color Pigeon 2.0 is not powered. Yel- Only a single LED Device is in boot-loader, most likely because firmware upgrad- low/Green will blink with this ing has failed. Inspect CAN bus wiring and retry firmware up- pattern.
  • Page 54 Phoenix Pro Chapter 7. Pigeon 2.0...
  • Page 55 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.
  • Page 56 Phoenix Pro LED Color Led Brightness CAN bus Detec- Magnet Field Description tion Strength CANcoder • • • pow- ered/plugged Check power cabling CAN- coder. Yellow/Green Bright Device • • boot-loader, most likely be- cause firmware upgrading failed. spect CAN bus...
  • Page 57 Phoenix Pro 8.2 Magnet Placement Using the CANcoder User’s Guide, verify that magnet placement is correct for the CANcoder. 8.3 Verifying Sensor Direction CANcoder sensor direction can be configured via the Config page in Phoenix Tuner X. 8.2. Magnet Placement...
  • Page 58 Phoenix Pro Chapter 8. CANcoder...
  • Page 59 API Usage This section serves to provide basic API usage for the Phoenix Pro API. For full details, please visit the API docs (Java, C++). Important: While Phoenix Pro and Phoenix 5 devices may exist on the same CAN bus and same robot project, each robot project must use the API tied to the device firmware version.

  • Page 60: Api Overview

    – A “cheat sheet” on migrating from Phoenix 5 to Phoenix Pro. 9.1 API Overview The Phoenix Pro API resides in the com.ctre.phoenixpro package in Java and the ctre::phoenixpro namespace in C++. The API is then further organized into smaller pack- ages and namespaces that group together similar types of classes and functions: •...

  • Page 61: Configuration Objects

    Phoenix Pro 9.2 Configuration Devices support persistent settings through the use of “configs”. Tip: Configs can also be configured using Phoenix Tuner X. See Tuner Configs for more information. 9.2.1 Configuration Objects There are device-specific Configuration classes that group configuration data of devices in a meaningful way.
  • Page 62 Phoenix Pro Java talonFXConfigurator m_talonFX.getConfigurator(); auto& talonFXConfigurator m_talonFX.GetConfigurator(); Reading Configs To read configs stored in a device, use the refresh() method to update a Configuration object. The example below demonstrates retrieving a full TalonFXConfiguration (Java, C++) object from a TalonFX device.

  • Page 63: Control Requests

    TalonFXConfiguration()); m_talonFX.GetConfigurator().Apply(configs::TalonFXConfiguration{}); 9.3 Control Requests Control Requests represent the output of a device. A list of control requests can be found in the API docs (Java, C++). Note: Phoenix Pro utilizes the C++ units library when applicable. 9.3. Control Requests...
  • Page 64 Phoenix Pro 9.3.1 Applying a Control Request Control requests can be applied by calling setControl() on the motor object. setControl() returns a StatusCode (Java, C++) enum that represents success state. A successful request will return StatusCode.OK. Java // Command m_motor to 100% of duty cycle m_motor.setControl(new...
  • Page 65 Phoenix Pro Method Chaining API Control requests also supports modification using method chaining. This can be useful for mutating multiple values of a control request. Java // initialize torque current FOC request with 0 amps motorRequest TorqueCurrentFOC(0); // mutate request with output of 10 amps and max duty cycle 0.5 m_motor.SetControl(motorRequest.withOutputAmps(10).withMaxDutyCycle(0.5));...

  • Page 66: Status Signals

    Note: Phoenix Pro utilizes the C++ units library when applicable. The StatusCode (Java, C++) of the signal can be retrieved by calling getError(). This can be used to determine if the device is not present on the CAN bus.
  • Page 67 Phoenix Pro Refreshing the Signal Value The device StatusSignalValue getters implicitly refresh the cached signal values. However, if the user application caches the StatusSignalValue object, the refresh() method must be called to fetch fresh data. Tip: The refresh() method can be method-chained. As a result, you can call refresh() and getValue() on one line.
  • Page 68 Phoenix Pro // wait up to 1 robot loop iteration (20ms) for fresh data supplyVoltageSignal.WaitForUpdate(20_ms); Changing Update Frequency All signals can have their update frequency configured via the setUpdateFrequency() method. Warning: Increasing signal frequency will also increase CAN bus utilization, which can cause indeterminate behavior at high utilization rates (>90%).
  • Page 69 Phoenix Pro Note: When using a non-zero timeout, the signals passed into waitForAll() should have the same update frequency for synchronous data acquisition. This can be done by calling setUpdateFrequency() or by referring to the API documentation. The following signals are time-synchronized: •...

  • Page 70: Device Faults

    API in RAM-constrained applications. 9.5 Device Faults “Faults” are status indicators on CTR Electronics CAN devices that indicate a certain behavior or event has occurred. Faults do not directly affect the behavior of a device; instead, they indicate the device’s current status and highlight potential issues.
  • Page 71 Phoenix Pro 9.5.1 Using API to Retrieve Faults Faults can also be retrieved in API using the getFault_*() (regular) or getStickyFault_*() (sticky) methods on the device object. This can be useful for diagnostics or error handling. Java faulted m_cancoder.getFault_BadMagnet().getValue(); (faulted) { // do action when bad magnet fault is set 9.5.
  • Page 72 A list of possible faults can be found in the API documentation for each device. 9.6 Enabling Actuators CTR Electronics supported actuators have a safety feature where they will automatically dis- able output if they have not recently received an enable signal.
  • Page 73 Phoenix Tuner 9.7 Actuator Limits CTR Electronics actuators, such as the TalonFX, support various kinds of hardware and soft- ware limits. Documentation on wiring limit switches can be found here. 9.7.1 Retrieving Limit Switch State The state of the forward or reverse limit switch can be retrieved from the API via getFor- wardLimit() and getReverseLimit().
  • Page 74 Phoenix Pro 9.8 Device Specific This section is intended to highlight any device specific API functionality. This include features such as the TalonFX + CANcoder fusion, details on using TalonFX Control Requests and more. 9.8.1 TalonFX Introduction to TalonFX Control The TalonFX has a variety of open-loop and closed-loop control requests and supports Field Oriented Control.
  • Page 75 Phoenix Pro Field Oriented Control Field Oriented Control (FOC) is a commutation mode that increases peak power by ~15%. All control modes that optionally support FOC have an EnableFOC field (Java, C++). There are also control types that require FOC, such as TorqueCurrentFOC.
  • Page 76 Phoenix Pro Closed-Loop Control Closed-loop control typically refers to control of a motor that relies on sensor data to adjust based on error. Systems/mechanisms that rely on maintaining a certain position or velocity achieve this state using closed-loop control. This is achieved by...
  • Page 77 Phoenix Pro Java // in init function, set slot 0 gains slot0Configs Slot0Configs(); slot0Configs.kS 0.05; // Add 0.05 V output to overcome static friction slot0Configs.kV 0.12; // A velocity target of 1 rps results in 0.12 V output slot0Configs.kP 0.11;...
  • Page 78 Phoenix Pro Converting from Meters In some applications, it may be useful to translate between meters and rotations. This can be done using the following equation: meters · gearRatio rotations = π · wheelDiameter where meters is the target in meters, wheelDiameter is the diameter of the wheel in meters, and gearRatio is the gear ratio between the output shaft and the wheel.
  • Page 79 Phoenix Pro Java // create a position closed-loop request, voltage output, slot 0 configs request PositionVoltage(0).withSlot(0); // set position to 10 rotations m_talonFX.setControl(request.withPosition(10)); // create a position closed-loop request, voltage output, slot 0 configs auto request controls::PositionVoltage{0_tr}.WithSlot(0); // set position to 10 rotations m_talonFX.SetControl(request.WithPosition(10_tr));...
  • Page 80 Phoenix Pro If the Motion Magic® jerk is set to a nonzero value, the generated velocity profile is no longer trapezoidal, but instead is a continuous S-Curve (corner points are smoothed). An S-Curve profile has the following advantaged over a trapezoidal profile: •...
  • Page 81 Phoenix Pro • Cruise Velocity - peak/cruising velocity of the motion • Acceleration - controls acceleration and deceleration rates during the beginning and end of motion • Jerk - controls jerk, which is the derivative of acceleration Using Motion Magic® in API Motion Magic®...
  • Page 82 Phoenix Pro // in init function configs::TalonFXConfiguration talonFXConfigs{}; // set slot 0 gains auto& slot0Configs talonFXConfigs.Slot0Configs; slot0Configs.kS 0.25; // Add 0.25 V output to overcome static friction slot0Configs.kV 0.12; // A velocity target of 1 rps results in 0.12 V output slot0Configs.kP...
  • Page 83 FusedCANcoder New in Phoenix Pro is a feedback sensor type called FusedCANcoder. FusedCANcoder will fuse another CANcoder’s information with the motor’s internal rotor, which provides the best possible position and velocity for accuracy and bandwidth. This is useful in applications such as swerve azimuth.
  • Page 84 Phoenix Pro Java /* Configure CANcoder to zero the magnet appropriately */ CANcoderConfiguration cc_cfg CANcoderConfiguration(); cc_cfg.MagnetSensor.AbsoluteSensorRange AbsoluteSensorRangeValue.Signed_ PlusMinusHalf; → cc_cfg.MagnetSensor.SensorDirection SensorDirectionValue.CounterClockwise_ Positive; → cc_cfg.MagnetSensor.MagnetOffset 0.4; m_cc.getConfigurator().apply(cc_cfg); TalonFXConfiguration fx_cfg TalonFXConfiguration(); fx_cfg.Feedback.FeedbackRemoteSensorID m_cc.getDeviceID(); fx_cfg.Feedback.FeedbackSensorSource FeedbackSensorSourceValue.FusedCANcoder; fx_cfg.Feedback.SensorToMechanismRatio 1.0; fx_cfg.Feedback.RotorToSensorRatio 12.8; m_fx.getConfigurator().apply(fx_cfg); /* Configure CANcoder to zero the magnet appropriately */ configs::CANcoderConfiguration cc_cfg{};...
  • Page 85 – Configuring and using closed-loop control requests • Feature Replacements – Other features replaced or improved upon in Phoenix Pro 9.9.1 Configuration Phoenix Pro simplifies the configuration process through the use of device-specific Configu- ration classes, as well as configuration groups. 9.9. Migration Guide...
  • Page 86 Phoenix Pro Applying Configs Java // set slot 0 gains // 50 ms timeout on each config call 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, 0.42, 50); // set slot 0 gains // 50 ms timeout on each config call m_motor.Config_kF(0, 0.05, 50);...
  • Page 87 Phoenix Pro Factory Defaulting Configs Java // user must remember to factory default if they configure devices in code m_motor.configFactoryDefault(); // user must remember to factory default if they configure devices in code m_motor.ConfigFactoryDefault(); Java // any unmodified configs in a configuration object are *automatically* factory- defaulted;...
  • Page 88 // fetch *all* configs currently applied to the device m_motor.getConfigurator().refresh(fx_cfg); configs::TalonFXConfiguration fx_cfg{}; // fetch *all* configs currently applied to the device m_motor.GetConfigurator().Refresh(fx_cfg); 9.9.2 Status Signals Phoenix Pro expands the functionality of status signals with the introduction of the Sta- tusSignalValue (Java, C++). Chapter 9. API Usage...
  • Page 89 Phoenix Pro 9.9. Migration Guide...
  • Page 90 Phoenix Pro Using Status Signals Java // get latest TalonFX selected sensor position // units are encoder ticks sensorPos m_talonFX.getSelectedSensorPosition(); // latency is unknown // cannot synchronously wait for new data // get latest TalonFX selected sensor position // units are encoder ticks sensorPos m_talonFX.GetSelectedSensorPosition();...
  • Page 91 // slow down the position signal to 5 Hz m_talonFX.GetPosition().SetUpdateFrequency(5_Hz); Important: Currently in Phoenix Pro, 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.
  • Page 92 Pigeon 2 Signals Note: Many Pigeon 2 signal getters in Phoenix 5 fill an array, such as YawPitchRoll. In Phoenix Pro, these signals have been broken up into their individual components, such as Yaw, Pitch, and Roll. Phoenix 5 Phoenix Pro...
  • Page 93 Phoenix Pro 9.9.3 Control Requests Phoenix Pro provides an extensive list of flexible control modes through the use of strongly- typed control requests. Using Control Requests Java // robot init, set voltage compensation to 12 V m_motor.configVoltageComSaturation(12); m_motor.enableVoltageCompensation(true); // main robot code, command 12 V output m_motor.set(ControlMode.PercentOutput, 1.0);...
  • Page 94 Phoenix Pro Chapter 9. API Usage...
  • Page 95 Phoenix Pro Follower Motors Java // robot init, set m_follower to follow m_leader m_follower.follow(m_leader); // m_follower should NOT oppose m_leader m_follower.setInverted(TalonFXInvertType.FollowMaster); // set m_strictFollower to follow m_leader m_strictFollower.follow(m_leader); // set m_strictFollower to ignore m_leader invert and use its own m_strictFollower.setInverted(TalonFXInvertType.CounterClockwise);...

  • Page 96: Closed-Loop Control

    Phoenix Pro Control Types In Phoenix Pro, voltage compensation has been replaced with the ability to directly specify control output type. All control output types are supported in open-loop and closed-loop control requests. Table 1: Open-loop Control Requests Phoenix 5...
  • Page 97 Phoenix Pro Position (DutyCycle) Velocity (DutyCycle) 9.9. Migration Guide...
  • Page 98 Phoenix Pro Chapter 9. API Usage...
  • Page 99 Phoenix Pro 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);...
  • Page 100 Phoenix Pro Chapter 9. API Usage...
  • Page 101 Phoenix Pro 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␣...
  • Page 102 Phoenix Pro. Motor Invert In Phoenix Pro, motor invert is now a persistent config (Java, C++) instead of a control signal. Neutral Mode In Phoenix Pro, 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++).
  • Page 103 Phoenix Pro Velocity Measurement Period/Window In Phoenix Pro, 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 Pro and have been removed.
  • Page 104 Phoenix Pro Chapter 9. API Usage...

  • Page 105: Supported Devices

    Simulation Phoenix Pro supports comprehensive simulation support. All hardware features are available in simulation, including configs, control requests, simulated CAN bus timing, and Phoenix Tuner X support. 10.1 Introduction to Simulation 10.1.1 Supported Devices Currently, all Phoenix Pro devices are supported in simulation.
  • Page 106 Phoenix Pro auto& talonFXSim m_talonFX.GetSimState(); Note: Phoenix Pro utilizes the C++ units library when applicable. Orientation The SimState API ignores typical device invert settings, as the user may change invert for any reason (such as flipping which direction is forward for a drivebase). As a result, for some devices, the SimState object supports specifying the orientation of the device relative to the robot chassis (Java, C++).
  • Page 107 Phoenix Pro Inputs and Outputs All SimState objects contain multiple inputs to manipulate the state of the device based on simulation physics calculations. For example, all device SimState objects have a supply volt- age input: Important: Non-FRC platforms are required to set supply voltage, as it affects simulation calculations.
  • Page 108 10.1.3 High Fidelity CAN Bus Simulation Many popular CTR Electronics CAN devices support high-fidelity simulation, where the in- fluence of the CAN bus is simulated at a level similar to what happens on a real robot. This means that the timing behavior of control and status signals in simulation will align to the same framing intervals seen on a real CAN bus.
  • Page 109 WPILib interfaces that FRC teams use. 11.1 MotorController Integration Phoenix Pro motor controller classes such as TalonFX (Java, C++) implement the Motor- Controller (Java, C++) interface. This allows Phoenix Pro motor controllers to be used in WPILib drivetrain classes such as DifferentialDrive. Java...

  • Page 110: Motor Safety

    Safety. In additional to the normal enable signal of CTR Electronics actuators, Motor Safety will automatically disable the device according to the WPILib Motor Safety implementation. 11.1.2 Simulation It’s recommended that users set supply voltage to getBatteryVoltage() (Java, C++) to take advantage of WPILib’s BatterySim (Java, C++) API.
  • Page 111 Phoenix Pro 11.2 Gyro Integration CTR Electronics IMUs, such as the Pigeon 2.0, implement the WPILib Gyro (Java, C++) in- terface. Note: calibrate() does nothing on the Pigeon 2.0, as it does not require manual calibration. 11.2. Gyro Integration...
  • Page 112 Phoenix Pro 11.2.1 Simulation The simulated device state is shown in the simulation Other Devices menu. Chapter 11. WPILib Integration...
  • Page 113 Examples Comprehensive API usage examples and tutorials. 12.1 Open-Loop Quickstart The below example showcases controlling a four-motor drivetrain. 12.1.1 Declaring Motor Controllers The TalonFX motor controller constructor (Java, C++) requires a device ID (int) and an optional CAN bus (string). Note: The name of the native roboRIO CAN bus is rio.
  • Page 114 Phoenix Pro C++ (Header) class Robot public frc::TimedRobot { private: static constexpr char const *kCANBus{"canivore"}; ctre::phoenixpro::hardware::TalonFX m_leftLeader{0, kCANBus}; ctre::phoenixpro::hardware::TalonFX m_rightLeader{1, kCANBus}; ctre::phoenixpro::hardware::TalonFX m_leftFollower{2, kCANBus}; ctre::phoenixpro::hardware::TalonFX m_rightFollower{3, kCANBus}; 12.1.2 Configure Followers & Inverts In a traditional robot drivetrain, there are two motors attached to each horizontal side of the drivetrain.
  • Page 115 Phoenix Pro Java @Override public void robotInit() { // start with factory-default configs currentConfigs MotorOutputConfigs(); // The left motor is CCW+ currentConfigs.Inverted InvertedValue.CounterClockwise_Positive; m_leftLeader.getConfigurator().apply(currentConfigs); // The right motor is CW+ currentConfigs.Inverted InvertedValue.Clockwise_Positive; m_rightLeader.getConfigurator().apply(currentConfigs); // Ensure our followers are following their respective leader m_leftFollower.setControl(new...
  • Page 116 Phoenix Pro (continued from previous page) private final TalonFX m_leftFollower TalonFX(2, kCANBus); private final TalonFX m_rightFollower TalonFX(3, kCANBus); private final DutyCycleOut m_leftOut DutyCycleOut(0); private final DutyCycleOut m_rightOut DutyCycleOut(0); private final XboxController m_driverJoy XboxController(0); @Override public void robotInit() { // start with factory-default configs currentConfigs MotorOutputConfigs();...
  • Page 117 Phoenix Pro (continued from previous page) m_leftLeader.GetConfigurator().Apply(currentConfigs); // The right motor is CW+ currentConfigs.Inverted signals::InvertedValue::Clockwise_Positive; m_rightLeader.GetConfigurator().Apply(currentConfigs); // Ensure the followers are following their respective leader m_leftFollower.SetControl(controls::Follower{m_leftLeader.GetDeviceID(), false}); m_rightFollower.SetControl(controls::Follower{m_rightLeader.GetDeviceID(), false}); void Robot::TeleopPeriodic() { // retrieve joystick inputs auto -m_driverJoy.GetLeftY(); auto m_driverJoy.GetRightX();...
  • Page 118 Phoenix Pro Chapter 12. Examples...
  • Page 119 • 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.
  • Page 120 Phoenix Pro Chapter 13. CANivore Intro...

  • Page 121: Supported Systems

    CANivore Setup 14.1 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) –...
  • Page 122 -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 Pro software for which you have purchased licenses. After adding the sources, the kernel module can be installed and updated using the following: sudo apt update...
  • Page 123 Phoenix Pro 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.
  • Page 124 Phoenix Pro 14.3 Field Upgrading CANivores A CANivore can be field updated using Phoenix Tuner Click or tap on the listed CANivore card: The CANivore can then be field upgraded via the dropdown or by manually selected a file: Chapter 14. CANivore Setup...
  • Page 125 Phoenix Pro Phoenix Tuner X also allows the user to batch field upgrade CANivores from the list of CANi- vores in the same manner as batch field upgrading devices. 14.4 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.
  • Page 126 Phoenix Pro Chapter 14. CANivore Setup...
  • Page 127 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.
  • Page 128 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. Table 1: Connection Messages...
  • Page 129 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.
  • Page 130 Phoenix Pro Java TalonFX m_motor TalonFX(0, "mycanivore"); hardware::TalonFX m_motor{0, "mycanivore"}; In VS Code, select the 3 dots in the top-right, then select Hardware Sim Robot Code A message in the console should appear that the CAN Bus is connected. ********** Robot program startup complete **********...

  • Page 131: Advanced Configuration

    Advanced Configuration The CANivore provides additional configuration options for advanced users. 17.1 CAN Bus Termination The CANivore has a 120 Ω 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.
  • Page 132 Phoenix Pro Chapter 17. Advanced Configuration...
  • Page 133 Phoenix Pro 17.2 caniv - CANivore CLI caniv is a Command-line Interface (CLI) to interact with CANivores outside of Phoenix Tuner 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 Win-...
  • Page 134 Phoenix Pro Chapter 17. Advanced Configuration...

  • Page 135: Troubleshooting

    Troubleshooting 18.1 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.
  • Page 136 Phoenix Pro 18.1.2 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.
  • Page 137 Phoenix Pro Note: Typically, there must be two 120-Ω 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.
  • Page 138 Phoenix Pro Chapter 18. Troubleshooting...
  • Page 139 Support CTR Electronics prides itself on excellent customer service. Our contact information can be found on our website.

Table of Contents