Skip to content

Auto planner: goal back, a new pickup spot per piece, stretch of three, visible robot state - #17

Merged
MBimrose merged 7 commits into
mainfrom
claude/jolly-wright-vz5il0
Nov 2, 2026
Merged

MBimrose merged 7 commits into
mainfrom
claude/jolly-wright-vz5il0

Conversation

@MBimrose

@MBimrose MBimrose commented Nov 2, 2026 •

Copy link
Copy Markdown
Member

Follow-up to #16.

Why the robot state didn't show

  • The browser kept the old script. The widgets loaded their scripts and styles without a version, and GitHub Pages lets browsers keep them for 10 minutes. After a deploy, a browser could pair the new page with the old planner script. That shows no real robot, no slip, no vision, and an empty chart and match panel.
  • It was too subtle at gentle limits. The real robot, the plan and the estimate sat on top of each other, and the camera state only appeared in the chart.

Changes

  • Cache busting. Every asset URL in _includes/interactive/*.html now ends in ?v=<build time>, so each deploy loads fresh files. This covers all widgets, not just the planner.
  • Field drawing:
    • an orange outline shows where the plan wants the robot
    • a dashed blue outline always shows where the robot thinks it is
    • a red ring appears round the robot while its wheels slip
  • Chips. Grip used, the camera's state (reading a tag, too blurred, or no tag in view) and pose error now show all the time. The clock and chips sit under the field, so they never cover the robot.
  • Goal back at x = 16.4, where it was before Auto planner: wheel slip, vision noise, 20 matches, and a 20 second period #16.
  • A new pickup spot for each piece. The single LOAD zone becomes one spot per piece, collected in order, so each trip is a different route:
    • PIECE 2 is in our alliance area at (4.4, 4.8): the slalom again.
    • PIECE 3 is low down between the barriers at (8.8, 1.0): a tight turn round the top of barrier B.
    • The next spot is drawn brightest, and a collected one is empty with a tick.
  • Two pieces is the task, plus a stretch goal of three.
    • Two pieces is forgiving: 40 of 64 settings work, anything from 3 m/s² up that isn't pushed too hard.
    • Three pieces in 20 s only fits with no stops (intake on the way into and out of each spot) and limits at the top of the balance. Only 5 of 64 settings do it: 5 m/s² at 4.5 m/s or more, or 3.5 m/s with 6 m/s².
    • At moderate limits (4 m/s, 5 m/s²) three pieces takes 20.0 s, just over. More acceleration slides the robot into B on the turn.
    • Stretch matches show as gold stars, and a stretch line appears under the checks. The stretch doesn't affect the main pass.
  • Page text updated: the exercise, the pickup spots, the balance table (two pieces vs the stretch), and the display guide.

Testing

  • node tools/validate-auto-task.js --grid passes. It checks:
    • two pieces at moderate limits works
    • most sensible settings work
    • very gentle limits run out of time
    • pushing hard fails
    • the stretch can be done, but not at moderate limits and not with stops
    • the route to piece 3 clears the barriers
  • tools/e2e: 8 planner tests and the page-load check pass in Chromium. Two errors from the sandbox blocking the mermaid CDN were filtered locally; the test helper itself is unchanged.
  • I checked the layout at 1280 px and 390 px.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CtC4MMv9XLZrAGLv712dF6

The five cards were shown in the order STEPS is written in, and that order
scores. A student could tap straight along the row and solve the exercise
without reading a single step, which is the whole point of the tutorial.

Shuffle the cards instead. Four of the 120 orders score, because the intake
keeps running once it starts and the robot can collect the game piece as it
drives through, so the shuffle rejects any arrangement that is one of those
four. Reading order is now never the answer.

Keep one student on one shuffle. The routine is already saved across visits,
so a bank that rearranged itself each time would not agree with the routine
under it. A saved order left over from an older list of steps is thrown away.

Add tools/validate-sequence.js. The guarantee rests on the list of working
orders being exact, so it replays all 120 orders through the real robot and
checks the list is still the whole set. The rules a step finishes by live in
a closure with no module to load, so the tool holds a copy and fails loudly
when that copy and the widget have parted.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CtC4MMv9XLZrAGLv712dF6
The planner used to treat the plan as what the robot does, so the best
answer was always the highest max speed and acceleration. Now each match
is simulated with ideas from maple-sim:

- The wheels grip up to about 8.8 m/s² (Colsons on carpet), shared
  between speeding up, slowing down and turning. Ask for more and they
  slip: the robot slides wide and odometry drifts.
- The drive motors 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.
- AprilTag readings correct the estimate the way WPILib's pose
  estimator does, noisier with distance and motion blur.
- The follower steers, and the shooter aims, by the estimate.

The routine runs as 20 matches, each with its own grip and camera noise,
and must work in 18. Moderate limits work with time to spare, gentle ones
run out of time, and pushing hard fails in more and more matches.

The widget draws the real path (red where slipping), where the robot
thinks it is, the plan's position, the tags, a speed / grip / pose error
chart, and the 20 matches to click through. The checks explain failures.
Barriers leave wider corridors and the goal is closer, so balanced limits
fit. The validator and browser tests prove the balance.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CtC4MMv9XLZrAGLv712dF6
…-forwards

Its content is already in main as c3e5ea9, so this merge changes no files.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CtC4MMv9XLZrAGLv712dF6
The autonomous period is 20 seconds, not 15. With two pieces, gentle
limits fit in 20 seconds, so there was no balance left to find. The task
is now three pieces: the preload, then two trips to the LOAD zone. The
LOAD zone moves to (4.4, 4.8), still in our alliance area, and the goal
to x = 12.8, so balanced limits fit with time to spare:

- 3 m/s², or less, is too slow at any max speed
- about 3 to 5 m/s with 5 to 6 m/s² works in 17.4 to 19 s
- 4.5 m/s and up with 7 m/s² or more fails in most matches
- the fastest setting that still works saves about 1.7 s

The validator's grid scales its "fast" line with the period, and prints
every setting with --grid.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CtC4MMv9XLZrAGLv712dF6
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CtC4MMv9XLZrAGLv712dF6
…ree, and visible robot state

Students could not see what the new physics was doing. The page loaded
the planner's scripts without a version, so a browser could keep the old
script for ten minutes after a deploy. At gentle limits the real robot,
the plan and the estimate also sat on top of each other.

- Every widget asset URL now carries the build time, so a deploy always
  loads fresh scripts and styles.
- The field draws where the plan wants the robot (orange outline), where
  the robot thinks it is (dashed blue outline, always), and a red ring
  while the wheels slip. Grip used, what the camera sees, and pose error
  are chips under the field, which no longer covers the robot.

The goal moves back to x = 16.4, where it was before. Two pieces is the
task again, and forgiving: 40 of 64 settings work, at 3 m/s² and up. The
stretch goal is a third piece in the same 20 seconds, and it only fits
with no stops (intake on the way in and out of the LOAD zone) and limits
at the top of the balance, such as 4 m/s and 7 m/s². Stretch matches
show as gold stars, with a stretch line under the checks. The validator
and browser tests prove both.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CtC4MMv9XLZrAGLv712dF6
The single LOAD zone becomes one spot per piece, collected in order, so
each trip is a different route. PIECE 2 waits in our alliance area at
(4.4, 4.8): the slalom again. PIECE 3, the stretch, waits low down
between the barriers at (8.8, 1.0), so the trip to it is a tight turn
round the top of barrier B.

That keeps two pieces forgiving (40 of 64 settings work) and makes the
stretch a real balance: it fits in 20 s only with no stops and 5 m/s²
(at 4.5 m/s or more) or 3.5 m/s with 6 m/s². Moderate limits take
20.0 s; more acceleration slides the robot into B on the turn.

The field draws each spot with its piece, brightest for the next one
and empty with a tick once collected. The page, validator and browser
tests follow the new spots.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CtC4MMv9XLZrAGLv712dF6
@MBimrose MBimrose changed the title Auto planner: goal back, two pieces with a stretch of three, visible robot state Auto planner: goal back, a new pickup spot per piece, stretch of three, visible robot state Nov 2, 2026
@MBimrose
MBimrose merged commit fcdab0b into main Nov 2, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants