Hardware Setup
This lesson powers up your mechanism. Nothing turns yet. No robot controller, and no code.
- The mechanism assembled and wired, with a charged battery. See Mechanism CAD.
- Phoenix Tuner X installed, from Prerequisites, and a USB cable to the CANivore.
Every mechanism here is three parts: a motor, a sensor that knows what the mechanism is doing, and a bus to your laptop. Tuner X is how you talk to all three.
The most important part of FRC programming is getting the hardware set up properly. If it's not set up properly, you'll be fighting it every step of the way.
The components
The arm uses all three. A flywheel has no CANcoder, because it is tuned for speed rather than angle, and the encoder inside the motor already measures speed. On a flywheel mechanism, read past the CANcoder wherever it comes up.

Kraken X44
A brushless motor with its controller built into the back. The inside runs position and velocity loops on the motor itself, a thousand times a second.
Free speed is about 125 rotations per second. It also reports its own position over the , so the motor is a sensor too.

WCP ThroughBore Encoder
An absolute position that mounts on a rotating shaft and reads a magnet. It still knows the arm angle after the power has been off all week.
The inside the motor does not. It reads zero wherever it happens to sit at boot. The parts list says ThroughBore. The part is a inside, and CANcoder is what the code calls it.

CANivore
A USB adapter that gives your devices their own CAN FD bus. It carries far more data per second than the bus built into the robot controller. Swerve drivetrains fill that one up, so they get a CANivore.
It is also why Workshop 1 needs no robot. The laptop plugs into the CANivore, and the CANivore talks to the devices.
Connect Tuner X
Power the mechanism first, then run USB from the laptop to the CANivore. There is no team number to type and no robot to find.
- Open and check CANivore USB.
- Set Team # or IP to
localhost. - The CANivore should appear in the device list within a second.
- Rename it to
canivore. Every later lesson and every code sample uses that name. - Open it and confirm the motor is listed under it, along with the CANcoder if you built the arm.
A CANivore that never shows up is usually running firmware older than the Tuner X you installed. Updating it is the next section.
Update the firmware
Tuner X and device firmware are versioned together. A device on old firmware still connects and still answers. It then refuses a configuration, or reports a signal your Phoenix version cannot read.
- Select one device, then use the batch update icon to flash every device of that model at once.
- Update the CANivore itself the same way.
- Put every device on the same version. Mixed versions on one bus give you failures that come and go.
- Check the card colours once the flashing finishes.
Card colour is the fastest read on the screen. The same meaning is printed under the device name, in words.
| Card | Meaning |
|---|---|
| Green | Device has the latest firmware. |
| Yellow | A newer version is available. |
| Purple | Unexpected or beta firmware version. |
| Red | Duplicate ID. Two devices answer to the same number, and Motor Setup sorts that out. |
| Blue | Tuner X could not download the list of firmware versions. |
Check your work
Power cycle the mechanism: battery off, USB out, then both back on. The firmware and the CANivore name are stored on the devices themselves.
You should see
- The CANivore reconnects as
canivore, with Tuner X still pointed atlocalhost. - The motor is listed under it, and the CANcoder too on the arm.
- Every device card is green.
- On the arm, turning the mechanism by hand changes the CANcoder position in Tuner X.
Check yourself
Which devices does the arm build use in this workshop?
What does the CANivore do?
What does a green device card in Tuner X mean?