USB Devices, Ordering, and the Operator Console

Port order is part of your code’s contract

In WPILib, every controller is referenced by a port number (0, 1, 2, 3, …). That port number maps directly to the device order in the Driver Station’s USB Devices tab — and the first six joystick slots are tracked, with their inputs sent to the robot. If your code expects the driver’s Xbox controller on port 0 and the operator’s on port 1, but the laptop enumerates them in the wrong order, your buttons will control the wrong subsystems. This is one of the most common and most embarrassing drive-team failures.

Locking device order

The Driver Station lets you make the order permanent (per WPILib docs):

• Drag a device to the slot you want; dragging automatically locks it to that position (shown with an underline/lock icon).
• Double-click a device to lock/unlock it manually.
• A locked device reserves its slot even when disconnected , so when you plug it back in it returns to the same port.
• Press Rescan (F1) to force the DS to re-detect devices (useful even when the robot is enabled).

Best practice: before your first match, plug in your controllers in a known order, drag-lock each to its intended slot, and verify the live axis/button feedback matches the right device. Then never change the USB hub or cable arrangement.

Building an operator console

Many teams go beyond off-the-shelf controllers and build a custom operator console (also called a button board or control board). Common building blocks:

• Arcade buttons and toggle switches wired into a USB encoder/interface board so each control appears as a joystick button to the DS.
• A panel or 3D-printed enclosure that holds the laptop and controls at a comfortable height.
• Off-the-shelf options like an Xbox controller for the driver (good thumbsticks for drivetrain) paired with a button board for the operator (dedicated buttons for each scoring action).

A dedicated button per action — “intake,” “score high,” “climb” — is faster and less error-prone under pressure than a single controller juggling combinations. The tradeoff is build effort and the risk of a wiring fault, so consoles should be inspected and tested just like the robot.

Console reliability

Whatever you build, treat the console as flight hardware: strain-relieve every cable, label each control, keep a spare controller in the pit, and bring a backup USB hub. The technician should be able to swap a failed controller in under a minute, because a dead controller mid-event is a fixable problem only if you prepared for it.

Key takeaways

• Controller port numbers in code map to the USB Devices order; the first six joystick slots are tracked and sent to the robot.
• Drag-lock or double-click devices so their slots are reserved even when unplugged.
• Custom operator consoles map one button per action for speed and reliability.
• Carry spare controllers/hubs and label and strain-relieve every cable.

This lesson was adapted from learnfrc.com.