Glossary of Terms

Motor Controller

Simple: A smart device that controls how a motor spins. Think of it like a dimmer switch for lights, but much smarter - it can control speed, direction, and precisely how far the motor turns.

Technical: An electronic device that manages power delivery to a motor while monitoring performance metrics like position, velocity, and current draw.

TalonFX / Kraken X44

Simple: A specific type of motor controller made by CTRE. The Kraken X44 is a motor with a TalonFX controller built right into it - like having an engine and transmission in one package.

Technical: CTRE's integrated brushless motor and motor controller unit featuring built-in FOC control, 1kHz PID loops, and CAN bus communication.

Encoder

Simple: A sensor that measures how far and how fast a motor has turned. Like a speedometer and odometer combined, but for motors instead of cars.

Real-world analogy: Imagine trying to park a car blindfolded - impossible! An encoder is like opening your eyes so you can see exactly where you are and how fast you're moving.

Technical: A rotary position sensor that provides feedback on shaft rotation, measured in rotations, degrees, or encoder ticks.

CANcoder

Simple: A standalone encoder that connects to the CAN bus. Unlike encoders built into motors, you can mount this anywhere to measure rotation of wheels, arms, or other mechanisms.

Technical: CTRE's absolute magnetic encoder that communicates over CAN bus, providing persistent position measurement even after power cycles.

CANivore

Simple: A device that creates a high-speed network for your robot's motors and sensors to talk to each other. Like a super-fast Wi-Fi router, but for robot parts instead of computers. It increases the refresh rate of motors from 50 Hz to 250 Hz, giving you more accurate odometry.

Technical: A USB-to-CAN FD interface that provides an additional CAN bus network with higher bandwidth and lower latency than the roboRIO's built-in CAN bus.

Phoenix 6

Simple: The latest software library from CTRE for controlling their motors and sensors. It's the "language" your code uses to talk to TalonFXs and CANcoders.

Technical: CTRE's API for communicating with v6 firmware devices, offering improved performance, FOC support, and simplified licensing compared to Phoenix 5.

CAN Bus

Simple: The communication network that connects motors, sensors, and the robot brain (roboRIO). Like a telephone line that lets all robot parts talk to each other using the same wire.

Technical: Controller Area Network - a robust communication protocol that allows multiple devices to communicate over a shared bus using unique device IDs.

Device ID

Simple: A unique number (like a name tag) given to each motor or sensor so your code knows which one to control. Like how each house has a different address.

Technical: A unique integer identifier (typically 1-62) assigned to each CAN device for addressing and communication on the network.

roboRIO

Simple: The "brain" of your robot. It's a small computer that runs your code and tells all the motors and sensors what to do.

Technical: National Instruments' embedded controller designed for FRC, running a real-time Linux operating system and WPILib framework.

Subsystem

Simple: A section of code that represents one physical part of your robot (like an arm, shooter, or drivetrain). It knows how to control its motors and read its sensors.

Real-world analogy: Think of your robot like a human body. The arm subsystem is like your actual arm - it knows how to move, knows where it is, and has specific jobs it can do.

Technical: A class extending SubsystemBase that encapsulates hardware (motors, sensors) and provides methods to control a specific robot mechanism.

Command

Simple: An action your robot performs, like "raise arm" or "shoot ball". Commands use subsystems to get things done.

Real-world analogy: If subsystems are body parts, commands are actions. "Raise arm" is a command that tells the arm subsystem what to do, just like your brain tells your arm to pick up a cup.

Technical: A schedulable unit of robot behavior that declares subsystem requirements and implements initialize(), execute(), isFinished(), and end() methods.

Trigger

Simple: A connection between a button press (or sensor reading) and a command. When you press button A, the trigger runs a specific command.

Real-world analogy: Like a light switch - when you flip it (trigger), the light turns on (command runs). The switch doesn't create light itself, it just tells the light what to do.

Technical: A boolean condition (from buttons, sensors, or custom logic) that schedules commands when its state changes using methods like onTrue() and onFalse().

Command-Based Programming

Simple: The main way FRC teams organize robot code. You divide your robot into subsystems (parts), create commands (actions), and use triggers (buttons) to make things happen.

Technical: WPILib's design pattern organizing code into subsystems, commands, and triggers, providing clear separation of concerns and automatic scheduling/conflict resolution.

CommandSwerveDrivetrain

Simple: A special class generated by Phoenix Tuner X that handles all the complex math for swerve drive. It connects CTRE's swerve logic with WPILib's command-based structure.

Technical: A generated class that extends CTRE's SwerveDrivetrain and implements the Subsystem interface, allowing it to be used as a subsystem in WPILib command-based robot code.

Periodic Method

Simple: A method that runs automatically every 20 milliseconds (50 times per second). Used for displaying data or monitoring sensors, NOT for controlling motors directly.

Technical: A method called by the command scheduler every robot loop iteration (20ms) for telemetry updates and state monitoring.

PID Control

Simple: A smart way to automatically control motors to reach exact positions or speeds. Instead of you constantly adjusting, PID does it automatically by measuring the error and correcting it.

Real-world analogy: Like cruise control in a car. You set a target speed (60 mph), and the car automatically adjusts the gas pedal to maintain that speed, even going uphill or downhill.

Technical: Proportional-Integral-Derivative controller that uses error feedback to automatically adjust motor output, minimizing the difference between desired and actual states.

kP (Proportional Gain)

Simple: How strongly the motor reacts to being away from the target. Higher kP = stronger reaction. Like pressing the gas pedal harder when you're further from your target speed.

Technical: The proportional gain coefficient determining motor output per unit of error (Output = kP × Error).

kI (Integral Gain)

Simple: Corrects for small steady errors that build up over time. Usually left at zero for FRC because it can cause instability.

When to use: Most FRC mechanisms don't need this. Only use if your mechanism consistently stops just short of the target.

Technical: The integral gain coefficient that accumulates error over time to eliminate steady-state error (Output = kI × ∑Error).

kD (Derivative Gain)

Simple: Slows down the motor as it approaches the target to prevent overshooting. Like easing off the gas as you approach a stop sign.

Technical: The derivative gain coefficient that responds to the rate of error change, providing damping to reduce oscillation (Output = kD × dError/dt).

Feedforward (FF)

Simple: A "smart guess" about how much power you need, based on physics rather than error. Instead of waiting for the motor to be wrong and then correcting it, feedforward predicts what's needed.

Real-world analogy: When carrying a heavy backpack upstairs, you automatically use more effort than on flat ground. You don't wait to slow down and then push harder - you predict you'll need more force.

Technical: Model-based control that predicts required output based on system physics (gravity, friction, velocity) rather than reacting to error.

kS (Static Feedforward)

Simple: The minimum voltage needed to overcome friction and get your mechanism moving from a standstill. Like the initial push needed to get a heavy door to start opening.

Technical: Static friction compensation - constant voltage applied to overcome static friction regardless of desired velocity.

kG (Gravity Feedforward)

Simple: Extra power needed to hold up an arm or elevator against gravity. The voltage changes based on the angle - horizontal arms need more help than vertical ones.

When to use: For arms, elevators, or anything fighting gravity. Not needed for wheels or horizontal mechanisms.

Technical: Gravity compensation coefficient that applies voltage proportional to the cosine of the mechanism angle to counteract gravitational torque.

kV (Velocity Feedforward)

Simple: How much voltage is needed per unit of speed. Helps the motor reach and maintain target speeds smoothly.

When to use: For flywheels, shooters, and any mechanism where speed control is important.

Technical: Velocity feedforward gain determining voltage per unit of target velocity (Volts = kV × TargetVelocity).

Motion Magic

Simple: An upgrade to PID that makes movements smooth instead of jerky. Instead of rushing to the target, it accelerates smoothly, cruises, then slows down smoothly.

Real-world analogy: Like an elevator - it doesn't instantly jump to full speed and slam to a stop. It accelerates smoothly when starting, maintains speed, then decelerates smoothly to arrive gently.

Technical: CTRE's trapezoidal motion profile generator that creates smooth velocity curves with controlled acceleration, cruise, and deceleration phases.

Closed-Loop Control

Simple: A control method that uses sensor feedback. The motor checks where it actually is (using an encoder) and adjusts automatically to reach the target.

Technical: A feedback control system where sensor measurements inform control decisions, creating a closed feedback loop (sensor → controller → motor → sensor).

Open-Loop Control

Simple: Direct voltage control with no sensor feedback. You tell the motor "run at 6 volts" and hope it does what you want. Simple but imprecise.

When to use: For testing motors, simple movements, or mechanisms where precision isn't critical (like running an intake).

Technical: Control without feedback - motor output is set directly without measuring actual performance or position.

WPILib

Simple: The main programming toolkit for FRC robots. It includes everything you need to write robot code - like Microsoft Word for documents, but WPILib is for robot code.

Technical: FRC's official software library providing robot framework, command-based programming structure, motor control, sensor integration, and development tools.

Phoenix Tuner X

Simple: A program that lets you test and configure CTRE motors without writing any code. You can spin motors, check sensors, update firmware, and tune PID values.

Technical: CTRE's device configuration and diagnostic tool for configuring, testing, and tuning Phoenix devices with live plotting and control.

Driver Station

Simple: The program that connects your laptop to the robot during matches. It shows you robot status, lets you enable/disable the robot, and displays error messages.

Technical: FMS-compatible software interface for robot communication, control mode selection, joystick input, diagnostics, and competition connectivity.

Git / Version Control

Simple: A system that saves every version of your code as you work. Like a super-powered "undo" button that lets you go back to any previous version of your code, even from weeks ago.

Real-world analogy: Like Google Docs version history, but for code. You can see what changed, who changed it, and restore old versions if needed.

Technical: Distributed version control system tracking code changes, enabling collaboration, branching, and code history management.

NetworkTables

Simple: A shared bulletin board for your robot. Your code can post numbers (like battery voltage) to it, and your laptop can read them. It's how dashboards get their data.

Technical: A publish-subscribe messaging system used in FRC to communicate data between the robot, driver station, and coprocessors over the network.

TunerConstants.java

Simple: A specific file generated by Phoenix Tuner X that contains all the settings for your swerve drive, like CAN IDs, gear ratios, and physical measurements.

Technical: A generated Java configuration file containing static constants that define the physical properties and electrical configuration of the swerve drivetrain.