Add open_door: grip and swing the fridge door along its hinge arc#263
Merged
Conversation
Coordinated obstacle+gripper sweep: arm pulls the passive door by its handle while software sweeps the door angle, re-placing the static door obstacle per step so collision-checking stays honest. Co-Authored-By: Claude Opus 4.8 <[email protected]>
Six tasks: fetch/verify frame system, config, computeDoorSweep, setDoorTheta, openDoor orchestrator, DoCommand wiring. Co-Authored-By: Claude Opus 4.8 <[email protected]>
- DoorOpenAngleDegs / DoorPivotDegreesPerStep config + getters (default 90/10) - computeDoorSweep: inclusive θ waypoints, direction-aware - setDoorTheta: rotate the static door obstacle about its hinge (origin) via the lockFilterFrame remove/re-add, handle chain rides along, panel geometry preserved Frame names are constants (fridge-door, fridge-handle-ball) per the live frame-system dump recorded in the plan's Task 0 findings. Co-Authored-By: Claude Opus 4.8 <[email protected]>
openDoor grips the fridge handle, sweeps the door open by re-placing the static door obstacle per θ step and tracking the ball with a rigid grasp offset, then releases and retracts. Gated by the running CAS like run_cup_flow; rebuilds the frame system on exit so the door mutation can't leak. Co-Authored-By: Claude Opus 4.8 <[email protected]>
Registers open_door in the dispatch table, documents the command and the door_open_angle_degs / door_pivot_degrees_per_step config fields, and tests that the command routes to openDoor's running-gate. Co-Authored-By: Claude Opus 4.8 <[email protected]>
…pose The grasp target is now the configured grasp frame's center (door_grasp_frame_name, default fridge-handle-ball) with the approach pose's orientation, so the gripper lands dead-on the handle and co-rotates with it through the swing. Removes the door-grasp switch pose; approach/retract stay authored. Collision set and sweep-tracked frame both derive from the same config param. Co-Authored-By: Claude Opus 4.8 <[email protected]>
door_approach_relative_pose is a RelativePose offset resolved against the live grasp frame (reusing composeCupPose / relativePoseToSpatial, the cup pickup pattern) instead of an authored switch pose. Its orientation is the grasp orientation; the standoff is its translation off the ball center. The gripper commands grip-point at the ball center and holds it through the swing. Drops the door-approach switch pose; door-retract stays authored. ponytail: retract still an authored pose and the offset resolves in world axes at the closed pose — fine for a first cut; revisit when integrating a general "relative-to-a-live-frame" pose concept. Co-Authored-By: Claude Opus 4.8 <[email protected]>
Retract now reuses door_approach_relative_pose resolved against the ball's open pose (composeCupPose on the swept ball center), commanding grip-point to the standoff. Removes the door-retract switch pose — open_door now needs zero authored poses, just door_approach_relative_pose. Gripper release still precedes the retract move. Co-Authored-By: Claude Opus 4.8 <[email protected]>
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Vijay Vuyyuru (vijayvuyyuru)
requested a review
from Nicolas Palpacuer (NickPPC)
July 17, 2026 19:54
…oor an action
Two fixes on top of the open_door work:
- Keep the grip-point orientation constant while pulling the door. The
sweep loop was riding a rigid grasp offset (Compose(ballNow,
gripperInBall)), so the commanded tool orientation rotated with the
door panel and twisted the wrist off the handle. Track only the ball's
point and hold the grasp orientation (from door_approach_relative_pose)
fixed instead. The handle knob is spherical, so the grasp doesn't
constrain wrist roll and a fixed orientation is correct.
- Convert open_door from a bespoke top-level DoCommand into a proper
execute_action action. openDoor now has the action signature
(ctx, cancelCtx) error and drops the running-gate/cancelCtx-capture/
refreshFrameSystemIfClean boilerplate that the executeAction wrapper
already provides, keeping only the door-specific context merge and
resetFrameSystem defer. Invoke via {"execute_action": "open_door"}.
Tests and README updated accordingly.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Nicolas Palpacuer (NickPPC)
approved these changes
Jul 21, 2026
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.
Summary
Adds an
open_doorcommand that grips the passive fridge door by its handle and pulls it open along its hinge arc, keeping motion planning collision-honest by re-placing the static door obstacle in the frame system at each swept angle. This is the first "coordinated obstacle + gripper sweep" in the codebase — unlike the existing pivot/circular primitives, the obstacle world changes between waypoints.Changes
computeDoorSweep(θ waypoints),setDoorTheta(rotate the static door obstacle about its hinge via thelockFilterFrameremove/re-add so the handle chain and panel geometry ride along), and theopenDoororchestrator — grip → per-θ re-plan sweep → release → retract, gated by therunningCAS and rebuilding the frame system on exit so the mutation can't leak.door_open_angle_degs(default 90),door_pivot_degrees_per_step(default 10),door_grasp_frame_name(defaultfridge-handle-ball), anddoor_approach_relative_pose(required) with getters.RelativePose/composeCupPosepattern, resolved against the live grasp frame instead of a detected centroid — grasp aimsgrip-pointat the ball center, approach/retract are the relative-pose standoff at the closed/open ball. No authored switch poses required.doorOpenCollisions(graspFrame)allows gripper↔grasp-frame contact during the pull.open_doorDoCommand.Testing
computeDoorSweep(count/endpoints/reverse),setDoorTheta(ball sweeps the arc, hinge fixed, panel geometry preserved), the rigid grasp offset riding rotation, the ball-relative approach derivation, and the config getters.open_doorroutes to therunning-gate guard.go build ./...,go test ./coffee/...,go vetall green.make lintwas not run (env has golangci-lint v1 vs the repo's v2 config) — needs a clean pass on a v2-linter machine.door_approach_relative_poseand tune the standoff/orientation; confirm the open direction (sign ofdoor_open_angle_degs); live-run{"open_door": true}and watch the arm + motion-viz door track together.Known follow-ups (flagged as
ponytail:deferrals)setDoorThetaentirely and make θ a plan input.Claude Code Prompts Used
🤖 Generated with Claude Code