Your endgame mechanism works in the shop. It fails at competition. This guide covers why that happens, how to design the sequence, how to program the trigger, and how to practice the endgame as a standalone drill until it's automatic.
Who this is for: Drivers and engineers who have a working endgame mechanism (elevation, hang, park, tip) but aren't executing it consistently in matches. If you don't have a mechanism yet, finish the build first.
๐ Why Endgames Fail Under Match Pressure
Endgame fails at competition almost always for the same three reasons, none of them mechanical:
The trigger is time-based but the driver is watching the wrong thing. If you rely on a countdown timer you're glancing at, you'll miss it when you're focused on defense or scoring.
The endgame sequence isn't a practiced drill. It works in a calm shop. Under match adrenaline, with 30 seconds left and an opponent in your face, untrained sequences collapse.
The sequence assumes a specific robot position that match chaos doesn't guarantee. If your hang requires being at a specific field location, but you're defending an opponent at 1:45, the sequence fails before it starts.
๐ฏ Define Your Endgame Trigger
Choose one and commit to it. Don't mix them.
Time-based with strategist call: Strategist watches the clock and says "endgame, now" at 1:45. Driver begins the sequence on that word โ not when they decide to look at a clock. This is the most reliable method because it offloads the cognitive load from the driver.
Score-based: If the team is ahead by N points, execute endgame. If behind by too much, continue scoring instead. Strategist makes this call. Requires the strategist to track the score accurately in real time.
Opportunistic: Driver executes endgame whenever they find themselves in position with 20+ seconds left. Requires no coordination but demands driver judgment under pressure. Use only if your endgame is fast (under 5 seconds).
๐ป Programming the Endgame Switch
Map your endgame sequence to a dedicated button combination โ not a single button. Single-button endgames trigger accidentally. Two-button combos don't.
// Two-button endgame trigger โ hold R2 + press Avoidopcontrol() {
while (true) {
// Normal driver control...
chassis.opcontrol_tank();
// Endgame: hold R2 + press A to triggerif (master.get_digital(pros::E_CONTROLLER_DIGITAL_R2) &&
master.get_digital_new_press(pros::E_CONTROLLER_DIGITAL_A)) {
runEndgameSequence();
}
pros::delay(10);
}
}
voidrunEndgameSequence() {
// Example: drive to zone, deploy hang
chassis.pid_drive_set(-12, 110); // back toward hang bar
chassis.pid_wait_quick_chain();
chassis.pid_turn_set(180, 90);
chassis.pid_wait();
hangMotor.move_absolute(1800, 100); // deploy hang mechanism
pros::delay(1500);
hangMotor.brake();
}
Never change the trigger button mid-season. Muscle memory is the point. Once your driver has drilled the button combo 50 times, changing it one week before a competition breaks that memory.
๐ฎ Practicing the Endgame Drill
The endgame must be drilled in isolation before it's drilled in a full match simulation. Here is the progression:
1
Cold-start reps from the endgame zone: Robot starts at the position where the endgame begins. Driver executes the full sequence on command. 10 reps. Target: 100% success rate before moving on.
2
Triggered reps from anywhere on the field: Robot anywhere. Strategist calls "endgame" at random. Driver must reach the zone and complete the sequence. 10 reps. Target: 90% success rate.
3
Full match simulation with endgame: 2-minute match against a partner robot or defense simulation. Execute the endgame at real time (1:45). 5 matches. Log how many times endgame scores vs misses.
4
Stress reps: Driver is running cycles. Partner robot plays light defense. Strategist calls "endgame." This is where sequence discipline breaks under distraction. The goal is to replicate match conditions.
โ When Endgame Works in Practice but Fails at Competition
You're in a different field position than expected: Add a second endgame route for when you're on the wrong side of the field. Shorter, simpler, guaranteed to at least park.
Defense disrupts the sequence start: Practice the endgame with a partner applying light contact. Your sequence must tolerate being bumped.
The driver doesn't hear the strategist call: Establish a non-verbal backup โ the strategist taps the driver's shoulder. At noisy events, voice alone isn't reliable.
The mechanism times out or stalls under load: Test the endgame under load โ with the robot at full weight, after driving 90 seconds. Motor temperature at match end is different from a cold start in the shop.
⚙ STEM HighlightEngineering: Sequential Systems Design & Timing Margins
A multi-step endgame sequence is a sequential state machine with timing margins. Each step requires a minimum time to complete, and the sequence must finish before match end with margin for mechanical variation. If step 1 = 3s, step 2 = 5s, step 3 = 8s, you must commit at T−16s minimum — but smart engineers add 20% margin for slow mechanisms, giving T−19s. This timing analysis is standard practice in any time-critical system from rocket launches to surgical robots.
🎤 Interview line: “We analyzed our endgame sequence by timing each step separately across 10 trials, taking the 90th percentile (not the average) as our planning time. Summing those gives our worst-case duration, and we commit with a 20% additional margin. This approach eliminated all our "ran out of time" failures — we now finish with 1–3 seconds to spare consistently.”
Your endgame has three steps averaging 2s, 4s, and 6s. You add 20% margin. When is the latest you should commit to starting the sequence?
⬛ T−12 seconds (just the sum of average times)
⬛ T−14.4 seconds (sum of averages with 20% margin)
⬛ T−10 seconds (only count the longest step)
📝
Notebook entry tip:Test & Evaluate — Cyan slide — Write a timing analysis entry for your endgame sequence. Time each step individually over 5+ trials, calculate the 90th percentile for each, sum them, add 20% margin, and document your commit trigger. This entry demonstrates engineering rigor — your commit time is a calculated result, not a guess.