Repository navigation
Auto planner: goal back, a new pickup spot per piece, stretch of three, visible robot state - #17
Merged
Merged
Conversation
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #16.
Why the robot state didn't show
Changes
_includes/interactive/*.htmlnow ends in?v=<build time>, so each deploy loads fresh files. This covers all widgets, not just the planner.Testing
node tools/validate-auto-task.js --gridpasses. It checks: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.🤖 Generated with Claude Code
https://claude.ai/code/session_01CtC4MMv9XLZrAGLv712dF6