[MBimrose]

The planner on How to Plan an Auto used to treat the plan as what the robot does, so the best answer was always the highest max speed and acceleration. Now each run simulates the robot on carpet, with ideas from maple-sim, and students have to find limits that are fast enough but still reliable.

The physics (assets/js/interactive/auto-core.js)

• Grip: the wheels grip the carpet up to about 8.8 m/s² (Colsons, coefficient 0.9 from maple-sim). Speeding up, slowing down and turning share that budget. Ask for more and the wheels slip, the robot slides wide, and odometry drifts.
• Motors: they top out at 4.75 m/s and lose acceleration near it. A plan faster than that leaves the robot behind, cutting corners and still moving when it shoots.
• Odometry and vision: odometry counts wheel turns, so slipping wheels make it drift. AprilTag readings correct it the way WPILib's pose estimator does. Readings get noisier with distance and blur with speed.
• Aiming: the path follower steers by the estimate and the shooter aims from it. A moving robot carries its shot off line.
• 20 matches: each match has its own grip (±5%) and camera noise, and the routine must work in 18 of 20.

The task

The autonomous period is now 20 seconds, as in the real game. With two pieces, gentle limits fit in 20 seconds and there was no balance left to find, so the task is now three pieces: the preload plus two trips to the LOAD zone. The LOAD zone moves to (4.4, 4.8), still in our alliance area, and the goal moves to x 12.8. The barriers leave wider corridors.

node tools/validate-auto-task.js --grid shows the balance with the three-piece route:

Limits	Result
3 m/s² or less	too slow at any max speed
about 3–5 m/s with 5–6 m/s²	works in 18–20 of 20 matches, 16.3–19 s
4.5 m/s and up with 7 m/s² and up	fails in most or all matches
4 m/s, 7 m/s²	the fastest setting that works: 15.9 s, 1.7 s faster than 4 m/s, 5 m/s²

The widget

• The field shows the real path (red where the wheels slipped), a dashed outline for where the robot thinks it is, a dot for where the plan wants it, and the AprilTags with a line when the camera reads one.
• A chart shows speed, grip used and pose error. It can be dragged to scrub through the match.
• 20 match squares can each be clicked to watch that match.
• The checks count failures across the 20 matches and suggest what to change.
• Max acceleration now goes up to 10 m/s², and the page starts at 3 m/s and 3 m/s².
• On phones the chips sit under the field instead of covering it.

The page has a new section on slip, odometry, vision and the balance, plus an updated display guide, limits and references.

Testing

• node tools/validate-auto-task.js passes. It checks that moderate limits work with 2.4 s of margin, actions run in series miss the period, a straight line hits barrier A, gentle limits are too slow, pushing fails, and fast plans rarely work.
• tools/e2e planner tests (6) and the page-load check pass in Chromium. Two console errors from the cloud sandbox blocking the mermaid CDN were filtered locally. They also happen on main, and the test helper is unchanged.
• I checked the layout at 1280 px and 390 px.

The branch includes a merge of the old claude/jolly-wright-vz5il0 history (already in main as #13), which changes no files.

---

Generated by Claude Code