Skip to main content
All hardware CAN IDs, analog input ports, and peripheral names are centralized in Hardware.java. Changing a motor or sensor ID requires updating only that one file — no other source files reference raw integer IDs directly.

CAN ID table

IDs follow a deliberate grouping scheme so the CAN bus stays organized and easy to audit:Swerve devices (IDs 1–12) live on the "Drivebase" CAN bus defined in CompTunerConstants/AlphaTunerConstants. All other devices — including the PDH (ID 1) — are on the default RoboRIO CAN bus, so the overlapping ID 1 does not cause a conflict.

Vision: Limelight NetworkTable names

Each Limelight is referenced by its NT table name string rather than an IP or index. VisionSubsystem reads these constants directly from Hardware.
Descriptive position names (e.g., limelight-front) will be assigned once camera mounting locations are finalized. For now, letters A/B/C correspond to the physical cameras in the order they were installed.

Swerve module IDs

Swerve drive, steer, and CANcoder IDs occupy the 1–12 range and are defined in CompTunerConstants and AlphaTunerConstants rather than Hardware.java, because they are generated by Phoenix 6 Tuner X. See Tuner Constants for the full per-module breakdown.

Subsystem enable flags

Subsystems.java exposes a SubsystemConstants inner class with boolean flags that gate each subsystem at startup. Setting a flag to false causes Subsystems to assign null for that subsystem, and all command bindings that depend on it are skipped. Composite flags are derived automatically:

Source reference

Changing any CAN ID on a live robot requires a full robot code redeploy and a matching change in the device’s Phoenix 6 configuration (either via Tuner X or through the device config API). Mismatched IDs will silently fail to communicate rather than throwing an obvious error.