Partner Controller — Two-Person Drive Team

// Section 01

When Two Controllers Beat One

A second controller is not always better — it depends on the game design, the robot’s complexity, and whether your team has two players skilled enough to stay coordinated under match pressure.

💡

The core question: does your robot have more simultaneous actions than one driver can execute without cognitive overload? If the driver is making more than 3–4 decisions per second, a partner controller can help. If the robot is relatively simple to operate, a second player adds communication overhead without a scoring benefit.

Games That Reward Two Controllers

Robots with 3+ active mechanisms — drive, intake, arm, and claw running simultaneously require more simultaneous inputs than one player can reliably execute at peak pace
End-game sequences that require precise timing — a partner who does nothing but manage end-game can execute it perfectly every match while the driver handles the final scoring cycles
High-speed games where every tenth of a second counts — a driver focused only on navigation is faster than one also managing mechanisms
Defensive play — a driver focused only on positioning executes defensive maneuvers more fluidly

When One Controller Is Better

The robot has 2 active mechanisms that one driver handles easily
The second player would spend most of the match with nothing to do — boredom and disengagement lead to mistimed inputs
Your two players have not had time to practice communication under match pressure — miscommunication between driver and operator is worse than one good player doing everything
The game penalizes accidental mechanism activation — a disengaged operator can accidentally bump a button

⚠️

Two controllers require 2x the practice time. The driver–operator pair must practice together, develop verbal communication shortcuts, and build shared situational awareness. Do not add a second controller the week before a competition without significant paired practice time.

1 / 5

// Section 02

Setting Up the Partner Controller in PROS

Adding a second controller in PROS is two lines of code. The full configuration is slightly more, but the foundation is straightforward.

The Two Controller Objects

PROS defines two controller slots: E_CONTROLLER_MASTER (the primary controller) and E_CONTROLLER_PARTNER (the second controller connected via tether). The partner controller must be physically tethered to the master controller using a smart cable — partner wireless operation is not used in VRC.

ℹ️

Tethering: connect the two controllers with a V5 smart cable using the dedicated tether port on the top of each controller. The Brain’s radio handles all wireless communication — the tether just extends the controller signals.

include/main.h or src/robot-config.cpp — declare both controllers

// Primary controller — driver pros::Controller master(E_CONTROLLER_MASTER); // Partner controller — operator pros::Controller partner(E_CONTROLLER_PARTNER);

Reading Partner Controller Inputs

Every method available on master is also available on partner. All button and joystick reading is identical — just use the partner object instead of master.

src/main.cpp — inside opcontrol() while loop

// Master controller — drives the robot chassis.opcontrol_tank(); // EZ Template reads master internally // Partner controller — operates mechanisms if (partner.get_digital(DIGITAL_R1)) { intake.move(127); } else if (partner.get_digital(DIGITAL_R2)) { intake.move(-127); } else { intake.move(0); } // Partner joystick for fine mechanism control (e.g. arm height) int armSpeed = partner.get_analog(ANALOG_LEFT_Y); if (abs(armSpeed) > 10) { // deadband arm.move(armSpeed); } else { arm.move(0); } // Macros on partner controller if (partner.get_digital_new_press(DIGITAL_Y)) { ScoreMacro(); // partner triggers the score sequence }

Partner Controller Screen

The partner controller also has an LCD screen you can write to. Use this to give the operator status information — current arm position, mechanism state, match timer countdown:

// Write status to partner controller screen // (do this in a separate task to avoid slowing the control loop) partner.print(0, 0, "ARM: %d", arm.get_position()); partner.print(1, 0 , "INTAKE: %s", intakeOn ? "ON" : "OFF"); partner.print(2, 0, "READY");

2 / 5

// Section 03

Dividing Responsibilities

The division between driver and operator should be decided deliberately — not left to whoever feels like pressing a button. Clear ownership prevents hesitation and simultaneous input conflicts.

Driver

All drive control (master joysticks)

Positioning the robot for pickups and scoring

Auton selector (if using Brain screen)

End-game positioning (driver navigates to position)

Emergency override of intake/mechanism if needed

Operator

All mechanism control (partner buttons)

Intake start/stop/reverse

Arm position and claw control

End-game mechanism initiation

Calling out opponent positions and time warnings

The Communication Protocol

Without a defined communication protocol, driver and operator will hesitate, talk over each other, or operate mechanisms at the wrong moment. Define these call-and-response pairs in practice and stick to them at competition:

Driver calls “Ready” when positioned for pickup → Operator runs intake
Driver calls “Score” when positioned at goal → Operator executes score macro
Operator calls “Loaded” when game element is secured → Driver moves to goal
Operator calls “15 seconds” → Driver navigates to end-game position
Operator calls “Climb” → Driver holds position, operator initiates climb sequence

🏆

Keep calls short — one word. Two-word max. Under match pressure with crowd noise, long verbal instructions get missed or misheard. “Ready” is better than “I am now in position for the intake.” Practice until the single-word calls are automatic.

Avoiding Simultaneous Input Conflicts

If both master and partner can control the same mechanism, accidental simultaneous inputs fight each other. The programmer’s job is to make this structurally impossible for critical mechanisms:

Assign each mechanism to exactly one controller. Drive goes to master only. Intake goes to partner only. Arm goes to partner only. No overlap on primary mechanisms.
Emergency overrides on master are acceptable for intake only — master R1/R2 as a fallback if the partner controller disconnects. Make this explicit in code with a comment so it is not accidentally expanded.
Test with both controllers actively pressing conflicting buttons to see what happens. The result should be predictable and safe, not erratic.

3 / 5

// Section 04

Partner Controller Button Mapping

The operator has 12 buttons and 2 joysticks — significantly more inputs than they will typically need. Design the map around what the operator needs most at their fingertips.

Operator Mapping Philosophy

The operator’s primary mechanisms should always be on the most accessible buttons. Unlike the driver, the operator’s thumbs are not committed to joysticks for driving — they can freely use face buttons. This means the priority order for the operator is different:

Most-used action → R1/R2 or L1/L2 (index finger bumpers — fastest access, no thumb movement)
Second most used → A/B/X/Y face buttons (right thumb — very accessible when not on joystick)
Macros and sequences → face buttons with rising-edge detection
Fine control (arm height, angle) → left joystick Y-axis
D-pad → preset positions (arm to high goal, mid goal, floor)
Right joystick → rarely used, consider leaving unused

Example Map — Intake + Arm + Claw Robot

Partner Controller Layout

L1Arm Up

R1Intake Forward

L2Arm Down

R2Intake Reverse

AClaw Toggle

BScore Macro

XArm to Floor Preset

YClimb Initiate

D-UpArm Preset: High Goal

D-DownArm Preset: Low Goal

Left Stick YArm fine control

Right Stick(unused)

4 / 5

// Section 05

Practicing as a Two-Person Drive Team

Two-person driving is a skill that has to be practiced together, not separately. The driver getting better alone and the operator getting better alone does not make the pair better.

Joint Practice Structure

Define the communication protocol first — before any practice run, write down the 5–6 one-word calls the pair will use. Post it somewhere both players can see it during practice.
Run mechanism drills together — the same Single Cycle Timer drill from the Driver Practice guide, but both players in their roles. Driver positions, calls “Ready,” operator acts. Time the full cycle.
Match simulations with both players — run a full 105-second simulation. Log the score. Debrief: where did communication break down? Where did the pair hesitate?
Stress-test communication — coach calls “disruption” mid-run. Driver calls out “changing route.” Operator adapts mechanism timing accordingly. This builds the flexibility needed for real match variability.
Practice with crowd noise — play crowd noise or music at moderate volume during practice. Verbal calls must be audible over ambient noise at a competition venue.

🏆

The two-player pair should log sessions separately from individual driver logs. Track the pair’s simulation score as a unit over time. Communication quality cannot be measured by individual practice — only paired practice reveals it.

At Competition — Pre-Match Ritual

Both players check their controller battery level before every match
Confirm the tether cable is connected and both controllers show linked on Brain screen
Driver selects autonomous on Brain screen — operator confirms verbally
Run through the communication call list once verbally before walking to the field
Operator stays at the field boundary opposite the driver during the match for the best vantage point on mechanisms

⚙ STEM Highlight Engineering: Human Factors & Interface Design

Two-controller drive team design is a human factors engineering problem — the same discipline that designs aircraft cockpits and surgical robots. The driver and operator are two humans in a human-machine system sharing one robot. Key principles: stimulus-response compatibility (right stick should control right-side mechanisms), cognitive load partitioning (driver handles navigation; operator handles mechanisms — separating concerns), and error prevention (interlock conditions prevent simultaneous conflicting commands). Communication protocol is essentially a network protocol — defined message types with agreed-upon responses.

🎤 Interview line: “Our two-controller setup applies human factors engineering. We partitioned cognitive load: the driver focuses entirely on navigation, the operator on mechanisms. We defined explicit communication calls to synchronize actions — essentially a protocol, like a simplified version of how pilots use checklists and callouts.”

🔬 Check for Understanding

Your driver takes a sharp turn while the operator simultaneously extends the arm. The robot tips. This is primarily a failure of:

Motor power limits — the motors couldn’t handle both actions

Communication protocol — the two actions should have been coordinated to prevent simultaneous high-CoG + turning

PID tuning — better PID would prevent tipping

Hardware design — the arm should be shorter

5 / 5