Skip to content

2. The Hardware Paradigm

To program a physical FRC mechanism effectively, you must understand the constraints of the electrical signals traveling exactly underneath your code. In FRC, code doesn’t just run; it actively bridges power systems and data packets.

The NI RoboRIO 2.0 is an embedded Linux computer. This is where your compiled Java code actually lives and executes. Every 20 milliseconds, the RoboRIO evaluates your code, parses sensor data, and issues torque commands outward.

The RoboRIO does not have native WiFi. A separate module—the Radio (like the Vivid-Hosting VH-109 or OpenMesh)—must be physically ethernet-connected to the RIO. Your laptop talks securely to the Radio, which then pipelines the connection.

The RoboRIO does not directly spin motors. Instead, it “talks” to them using a protocol called CAN (Controller Area Network).

  • The CAN Bus is a literal yellow and green wire daisy-chained sequentially through every motor controller.

  • Because data flows serially, every motor requires a unique CAN ID (a number from 1 to 60) so the RoboRIO can target exactly who to command.

  • The CANivore: MARSLib utilizes CTRE hardware heavily. Standard RoboRIO CAN processing becomes bogged down around 50% utilization. We route all drivetrain components into a separate USB CANivore card, isolating high-bandwidth torque streams and speeding up loop times substantially.

An FRC battery supplies ~12V of DC electricity. However, when 14 different high-torque motors try to pull max acceleration simultaneously, the physical laws of electric load cause the battery voltage to momentarily crash down toward 6.0V.

If the voltage drops below 6.3V, the RoboRIO forcefully severs all motor connection to prevent the main CPU from dying. This is known as a Brownout. In MARSLib, we must dynamically shed power and strictly enforce motor current caps to avoid stalling the battery.