Skills Autonomous in EZ Template

flowchart TD
    Start([Designing a skills auton]) --> Q1{Driver skills
or programming skills?}
    Q1 -->|"Driver skills"| Driver[Full 60s driver control
no auton at all
practice on practice field]
    Q1 -->|"Programming skills"| Prog[Full 60s autonomous
no driver input allowed
different routine entirely]
    Prog --> Plan[Plan 4-6 scoring loops
each loop: grab → score → return]
    Plan --> Q2{Sensor-gated
or timed?}
    Q2 -->|"Sensor-gated (preferred)"| Sensor[More reliable
but each loop takes 8-12s]
    Q2 -->|"Timed (faster)"| Timed[Each loop 5-8s
but missed grab cascades]
    Sensor --> Test[Practice 10+ runs
note consistency]
    Timed --> Test
    Test --> Q3{Runs reliably?}
    Q3 -->|"Yes"| Compete([Run at event])
    Q3 -->|"No"| Iterate[Adjust constants
or simplify]
    Iterate --> Test

    style Start fill:#1e293b,stroke:#22d3ee,stroke-width:2px,color:#e2e8f0
    style Compete fill:#1e293b,stroke:#22c55e,stroke-width:2px,color:#e2e8f0
    style Q1 fill:#fbbf24,color:#0f172a,stroke:#fbbf24
    style Q2 fill:#fbbf24,color:#0f172a,stroke:#fbbf24
    style Q3 fill:#fbbf24,color:#0f172a,stroke:#fbbf24

60 seconds, solo, maximize points. Skills is a completely different design problem than match auton — longer chains, mid-run IMU resets, and consistency over raw speed. This guide builds the framework.

Plan on paper before touching code. A skills route has checkpoints — discrete positions where the robot should be at specific times. Work backwards from 60 seconds.

Always budget 5 seconds of slack. A skills run that finishes at exactly 60.0 seconds is one slipped wheel away from not completing its final score. Build in margin.

void Skills() {
  // ── Initialization ────────────────────────────────────
  chassis.pid_targets_reset();
  chassis.drive_imu_reset();
  chassis.drive_sensor_reset();
  chassis.drive_brake_set(MOTOR_BRAKE_HOLD);

  // ── Zone 1 (0–15s) — score near start ────────────────
  chassis.pid_drive_set(24_in, DRIVE_SPEED, true);
  chassis.pid_wait_until(8_in);
  intake.move(127);          // start intake on the way
  chassis.pid_wait();
  chassis.pid_turn_set(90_deg, TURN_SPEED);
  chassis.pid_wait_quick_chain();

  // ── Mid-run IMU recalibration ─────────────────────────
  // After ~25s of movement, IMU may have drifted 1–2 degrees.
  // Reset at a known heading reference (wall contact).
  chassis.drive_imu_reset();   // reset to 0 at current heading

  // ── Zone 2 (15–35s) — far field scoring ──────────────
  chassis.pid_drive_set(36_in, DRIVE_SPEED, true);
  chassis.pid_wait();
  // ... more moves

  // ── Zone 3 (35–55s) — return and score ───────────────
  chassis.pid_drive_set(-36_in, DRIVE_SPEED, true);
  chassis.pid_wait();
  intake.move(0);
}

After 30+ seconds of motion, IMU drift accumulates. A well-placed drive_imu_reset() at a known orientation (usually after driving into a wall or field element) corrects the drift before the robot enters a new zone. Rules to follow:

• Reset at a heading you know: After driving dead straight into a wall and stopping, your heading is either 0°, 90°, 180°, or 270°. Call drive_imu_reset() there.
• Don't reset mid-turn: Only reset at the start or end of a segment, never during a turn command.
• Once per zone boundary is enough: More resets aren't always better — each one assumes your heading is exactly what you think it is.