Conversation
- Verdict remembers the goal it just decided: target, deciding reading, outcome - the next goal, with the same target and that reading at acceptance, gets the outcome on its first cycle - a goal accepted in between, a timeout or a deactivation clears the memory - compat::goalPosition reads the target from GripperCommand and ParallelGripperCommand goals - test the carry-over and its guards in Verdict, and a repeated goal through both controllers Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ebarnett3
marked this pull request as draft
September 30, 2026 05:24
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
1 participant
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.
Closes #102.
With
use_object_statuson, re-sending the goal the gripper just stopped short of, typically a second close on a held object, waited outobject_status_timeout(10 s) and aborted with both flags false. The gripper does not act on a target it already settled on, soobject_detectionnever changes from the previous verdict, and the verdict rule waits for exactly that change.Verdictnow remembers the goal it just decided: its target, the reading that decided it, and the outcome. The next goal gets that outcome on its first cycle when its target is the same and its reading at acceptance is still that one. Anything else keeps the current rule: a different target, a changed reading, a goal accepted in between (it may already have moved the fingers), a goal that timed out, or the first goal after a deactivation. Effort and velocity are ignored, since the bench on #102 showed the firmware does not re-act on them alone. Targets are compared exactly, so two targets that round to the same register count still wait out the timeout, as before.Verified with
Verdictunit tests for the carry-over and each guard, and a repeated goal through both controllers, each failing with the carry-over disabled. Built and tested on Jazzy, and inros:humbleandros:lyricalcontainers. Bench, 2F-85 on Jazzy, closing 0.8 on an object four times: the first goal stalled 0.55 s after acceptance, each repeat stalled 0.05 s after acceptance (one action-monitor period) withobject_detectionstaying 2; before, each repeat aborted after 10 s. Free open/close repeats are unchanged.🤖 Generated with Claude Code