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 inCompTunerConstants 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: