CTRE Phoenix for FRC: Kraken X60/X44, TalonFX, Phoenix 6, CANcoder & Pigeon 2

If your robot has a motor that sounds like a jet spooling up and reports its own velocity back to code, odds are you are looking at the CTR Electronics stack. CTRE (Cross The Road Electronics) builds the Kraken motors, the TalonFX controllers baked inside them, the CANcoder and Pigeon 2 sensors that tell your mechanisms where they are, and the Phoenix 6 software that ties all of it together in Java, C++, or Python. It is one of the two big electronics ecosystems FRC teams standardize on, and once you understand how the pieces fit, wiring and programming a subsystem gets a lot less intimidating.

This guide walks the whole CTRE Phoenix ecosystem the way a veteran on your team would explain it: the Kraken X60 and X44 motors and what "TalonFX-integrated" actually means, the Phoenix 6 API and the Pro/FOC licensing model, the CANcoder and Pigeon 2, the CANivore and CAN FD bus, and Phoenix Tuner X for setup. We will finish with an honest CTRE-versus-REV comparison so you can decide what belongs on your robot. Every spec below was pulled from CTRE and WestCoast Products documentation, not memory.

The CTR Electronics ecosystem, at a glance

CTRE's design philosophy is vertical integration. Instead of selling a motor and a separate speed controller and a separate encoder, they ship devices that combine those roles and talk to each other over one CAN bus. The Kraken motors have the controller and encoder built in. The CANcoder is an encoder that speaks CAN directly. The Pigeon 2 is an IMU on the same bus. And every one of those devices is configured, controlled, and updated through a single software library called Phoenix 6.

That consistency is the real selling point. One API object model, one configuration tool, one licensing system, and one wire protocol cover motors, sensors, and the gyro. If you learn how to drive a TalonFX in code, you already mostly know how to read a CANcoder, because they share the same signal, configuration, and status-frame patterns. For a broader look at how this compares to the other major stack, see our writeup on the REV Robotics ecosystem.

Kraken X60 and X44: motors with a controller inside

The headline products are the Kraken motors, developed by WestCoast Products and powered by CTRE's TalonFX motor controller. The word "powered by Talon FX" is doing real work: the motor controller is not a separate brick zip-tied to your frame, it is integrated into the back of the motor. You run power and a CAN connection to the motor and that is it — no external controller, no separate encoder cable.

What "TalonFX-integrated" means

Every Kraken ships with the TalonFX controller and a high-resolution encoder built into the housing. That gives you onboard closed-loop control — Position, Velocity, Motion Magic, and Motion Magic Velocity modes — running on the motor itself at a 1 kHz control rate, rather than round-tripping through the roboRIO. Practically, this means smoother control loops and less CAN traffic, because the motor closes the loop locally and just reports status back.

The Kraken X60 is the full-size NEO/Falcon-class motor for drivetrains and heavy mechanisms. The Kraken X44 is a smaller, lighter motor built for tight spaces — shooters, hoods, intakes, and turrets — where the X60 is overkill on size and weight but you still want a real controller and encoder onboard.

Kraken X60 vs Kraken X44 specs

Here are the verified numbers from WestCoast Products' motor-performance documentation. Both motors support two commutation modes: standard trapezoidal, and Field Oriented Control (FOC), which requires a Phoenix Pro license. FOC trades a little free speed for more torque and roughly 15% more peak power.

A few things jump out. The X44 actually spins faster than the X60 at free speed but produces well under half the torque — it is a high-speed, low-torque motor you gear down, not a drivetrain workhorse. And notice how FOC changes the shape of every motor: the X60's stall torque climbs from 7.09 to 9.37 N·m and peak power from 1,108 to 1,405 W, all from a software commutation mode.

Current limits are not optional. Those stall-current figures — 366 A for an X60, and 483 A with FOC — are the theoretical worst case with the motor locked. You never want to actually pull that. Set supply and stator current limits in your TalonFX config so a jammed mechanism trips gracefully instead of browning out the robot or popping a breaker. CTRE's docs have a whole section on improving performance and reliability with current limits.

The X60 runs on a 6–24 V supply, hits about 87% max efficiency around 30 A, uses a SplineXS output shaft, and is assembled and QA-tested at CTRE's Michigan HQ. If you are weighing Krakens against NEOs and the older Falcon 500, our FRC motors deep dive puts them side by side.

Reading the FOC numbers

Field Oriented Control is a smarter commutation strategy: instead of the coarse six-step trapezoidal switching, FOC continuously orients the stator's magnetic field 90 degrees to the rotor for maximum torque per amp. That is where the extra torque and power come from. The catch is that FOC is a licensed Pro feature — the hardware can do it, but you have to pay to unlock it. More on that below.

TalonFX and TalonFXS: the controller side

The TalonFX is the controller integrated into every Kraken. In code it is a first-class Phoenix 6 device with three base control output types you build every request from:

• DutyCycle — raw percent output, the simplest "just spin" mode.
• Voltage — compensated voltage output, so behavior stays consistent as battery voltage sags.
• TorqueCurrentFOC — directly command motor torque via current, the highest-fidelity mode (and FOC, so it needs Pro).

On top of those, you layer closed-loop requests: position control, velocity control, and Motion Magic profiled motion. Because the loop runs on the TalonFX at 1 kHz, you get tight control without saturating the CAN bus with high-rate setpoints from the roboRIO.

TalonFXS and the Minion

The TalonFXS is CTRE's standalone, versatile motor controller — think of the "S" as the un-integrated sibling of the Kraken's built-in TalonFX. It is a separate controller board that drives both brushed motors and hall-sensored brushless motors, including CTRE's own Minion brushless motor and various third-party motors. It runs the same Phoenix 6 API — same PID control, motion profiling, and status framework — so nothing you learned about the TalonFX goes to waste. The TalonFXS is the piece that lets a CTRE-standardized team run a legacy brushed motor (a window motor, an AndyMark bag-style motor, a small brushed mechanism) or the Minion without leaving the Phoenix ecosystem.

Phoenix 6: the software

Phoenix 6 is the current-generation CTRE software library and the layer you actually write against. It is a ground-up redesign from the older Phoenix 5, with a cleaner device-and-signal model, better simulation support, and a unit-aware API.

Languages and control requests

Phoenix 6 supports Java, C++, and Python for FRC. The programming model is consistent across devices: you construct a device object (a TalonFX, CANcoder, or Pigeon2), configure it once with a strongly-typed configuration object, read live data through status signals, and command motion by applying control requests. Signals are unit-aware, so a velocity comes back as an actual rotations-per-second quantity rather than a raw sensor tick you have to scale by hand.

Simulation is built in. Phoenix 6 devices work in WPILib simulation without a robot on the bench, so your programmers can validate control logic, autonomous paths, and unit conversions before the mechanism is even wired. For a rookie programmer, that shortens the feedback loop dramatically.

Phoenix Pro and FOC licensing

This is the part every team asks about. Phoenix 6's core API is free — you can run Krakens, CANcoders, and a Pigeon 2 in trapezoidal mode at no cost. Phoenix Pro is a paid license that unlocks advanced features, most notably Field Oriented Control (FOC) and higher-fidelity data logging.

Licensing works one of two ways:

• Per device — activate a single TalonFX, CANcoder, or Pigeon 2 for Pro. CANcoder and Pigeon 2 are eligible for single-device licensing.
• Per CANivore bus — license the CANivore itself, and every compatible device on that bus becomes Pro-enabled with no additional activation. For a robot with a stack of Krakens, licensing the bus is usually the sensible move.

You buy licenses on the CTRE store and activate them through the LIC icon in Phoenix Tuner X. Batch activation is supported, and devices Tuner X has seen before can be licensed offline through Device History.

Activation is permanent. CTRE's docs are explicit: license activation is permanent and irreversible, and it binds to the specific device. Plan your licensing before you activate — you cannot move a per-device license to a different unit later, so bus licensing gives you the most flexibility if you swap motors between builds.

CANcoder and Pigeon 2: sensing the mechanism

Motors tell you where the motor shaft is. For real mechanisms you often need to know where the output is — the absolute angle of a swerve module, an arm, or a turret — and that is where CTRE's dedicated sensors come in.

CANcoder

The CANcoder is a high-performance rotary magnetic encoder that communicates over the CAN bus directly, no analog wiring or roboRIO DIO ports involved. It gives you an absolute position reading, which is exactly what you need for a swerve steering module: on power-up, the module instantly knows its wheel angle instead of needing a homing routine. It supports both CAN FD and classic CAN 2.0, so it drops onto either bus. If swerve is on your roadmap, our swerve drive explainer covers where the CANcoder fits in a module.

Pigeon 2

The Pigeon 2 is CTRE's IMU — a 9-axis inertial sensor that gives you robot heading (yaw), plus pitch and roll and raw gyro/accelerometer data, over CAN. Heading is the backbone of field-oriented drive and every odometry/pose-estimation scheme, so the Pigeon 2 is effectively a required part on a modern swerve robot. Like the CANcoder, it is eligible for single-device Pro licensing if you need the enhanced data features, though basic heading works on the free API.

Because both sensors are native CAN devices in the Phoenix 6 object model, you read them with the same signal API you use for a TalonFX. One mental model covers motors and sensors alike.

CANivore and CAN FD: the bus

Every CTRE device shares a CAN bus, and CTRE's answer to a crowded bus is the CANivore — a robust USB-to-CAN FD adapter that adds a second, faster CAN bus to your robot. CAN FD ("Flexible Data-rate") is a newer CAN standard with much higher throughput than classic CAN 2.0, which matters when you are streaming high-rate status frames off eight Kraken drivetrain motors plus steering motors and sensors.

Teams typically hang their whole swerve drivetrain — drive motors, steer motors, CANcoders, and the Pigeon 2 — off a CANivore bus and leave everything else on the roboRIO's built-in CAN bus. Two benefits stack up: you get the CAN FD bandwidth headroom, and, as covered above, licensing the single CANivore Pro-enables every device on that bus at once.

CAN FD is not backward-friendly on the same wire. Only CAN FD-compatible devices can operate on a CAN FD bus. If you put the drivetrain on a CANivore, keep non-FD or third-party devices on the roboRIO bus. For the fundamentals of how CAN wiring, addressing, and termination work, read our FRC CAN bus guide.

Phoenix Tuner X

Phoenix Tuner X is the desktop/companion app for the whole ecosystem. It is where you assign device IDs, update firmware, run self-tests and plots, blink a device to find it in the wiring, and — importantly — buy-side manage and activate your Phoenix Pro licenses through the LIC icon. When a new device comes out of the box, Tuner X is the first tool you open. When a motor is misbehaving mid-competition, its live plotting and self-test are the fastest way to see whether the problem is electrical, mechanical, or in code.

CTRE vs REV: choosing an ecosystem

Most teams standardize on one of two stacks, CTRE Phoenix or REV, mostly so their pit crew only carries one set of spare parts and their programmers only learn one API. Here is an honest side-by-side of the current landscape.

Neither stack is universally "better." CTRE's edge is the tightly integrated Kraken-plus-TalonFX package, high onboard control rates, and FOC for teams that want maximum power density and will pay for the Pro license. REV's edge is a simpler no-per-feature-license cost model and controllers you can pair with a range of motors. Plenty of strong teams mix both — Krakens on the drivetrain, REV parts elsewhere — though a single ecosystem keeps spares and code simpler. Whatever you pick, the power distribution hub and CAN wiring underneath are the same battle, and our full learning guides walk through wiring a subsystem end to end.

Frequently asked questions

Do I have to buy Phoenix Pro to use a Kraken X60?

No. The core Phoenix 6 API is free and runs Krakens, CANcoders, and the Pigeon 2 in standard (trapezoidal) mode. Phoenix Pro is only required to unlock Field Oriented Control and the enhanced data-logging features — everything else works without a license.

What is the difference between TalonFX and TalonFXS?

The TalonFX is the motor controller integrated inside every Kraken motor. The TalonFXS is a separate, standalone controller that drives brushed motors and hall-sensored brushless motors — including CTRE's Minion — using the same Phoenix 6 API. Use the TalonFXS when you want a non-Kraken motor inside the CTRE ecosystem.

How much faster does FOC make a Kraken X60?

FOC does not add free speed — it actually drops it slightly, from 6,000 to 5,800 RPM. What it adds is torque and power: stall torque climbs from 7.09 to 9.37 N·m and peak power from 1,108 to 1,405 W, roughly a 15% peak-power gain. It is a torque-and-power upgrade, not a top-speed one.

Do I need a CANivore to run Krakens?

No. Krakens, the CANcoder, and the Pigeon 2 all run on the roboRIO's built-in CAN bus. A CANivore adds a second CAN FD bus with more bandwidth — useful for a full swerve drivetrain — and conveniently Pro-licenses every device on that bus with one activation.

What does the CANcoder do that a motor's built-in encoder cannot?

The Kraken's built-in encoder tracks the motor shaft, but it is not absolute at the mechanism's output. A CANcoder reads the absolute angle of the output — a swerve module's wheel direction, an arm's angle — so the mechanism knows where it is the instant it powers on, no homing routine needed.

Can I program CTRE devices in Python?

Yes. Phoenix 6 officially supports Java, C++, and Python for FRC. The device object model, configuration objects, status signals, and control requests are consistent across all three languages, so tutorials written for one translate cleanly.

Get the CTRE ecosystem straight in your head once and the rest of the build gets easier: a Kraken is a motor with a TalonFX and encoder inside, Phoenix 6 is how you talk to it, the CANcoder and Pigeon 2 handle absolute position and heading, and the CANivore gives you a faster bus when you need it. Start with a single motor on the bench in Phoenix Tuner X, get it spinning in DutyCycle mode, then add a closed-loop control request — and you will have touched most of the stack in an afternoon.