# Dexterous Arm-Hand Extension > Generated from repository source files. Do not edit this page directly; edit the source file listed below and rerun `vp run docs:generate`. > Source: `research/09-dexterous-arm-hand-extension.md` ## Dexterous Arm-Hand Extension Direction Status: `exploratory direction; pre-evidence and pre-hardware selection` This page evaluates a possible extension of `SAH-BRI-Grasp`: combine a self-designed robot arm with an open-source dexterous hand while keeping non-invasive EEG at the high-level intent layer. This is not part of the current validated system. It is a staged research direction that should not block Exp1-Exp4. ## Direction Summary The useful research change is not simply replacing a two-finger gripper with a multi-finger hand. The stronger direction is to expand the command hierarchy: ```text scene object -> task intention -> grasp skill -> arm-hand plan -> contact-aware execution -> verification or recovery ``` The BCI should not control individual hand joints. SSVEP and MI should continue to express sparse, high-level choices, while robot autonomy resolves grasp type, arm trajectory, finger trajectory, contact handling, and recovery. Claim status: `inferred` from the existing high-level-intent and shared-autonomy design. No local dexterous-hand experiment currently verifies it. ## Relationship To The Current System | Layer | Current SAH-BRI-Grasp | Possible Arm-Hand Extension | Status | | -------------- | -------------------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------ | | user intent | select object; confirm, cancel, pause, or stop | select object and, when needed, task or grasp preference | `inferred` | | command space | scene objects become selectable candidates | scene objects expand into object-task-skill candidates | `inferred` | | robot autonomy | plan approach and grasp execution | coordinate arm motion, hand preshape, closure, contact response, and recovery | `needs confirmation` | | end effector | hardware and gripper are still TBD | open-source dexterous hand mounted on a self-designed arm | `needs confirmation` | | evidence | component literature and Exp1-Exp4 protocols exist | no dedicated dexterous-hand corpus, hardware record, or experiment exists | `verified` as repository state | The first physical closed-loop milestone should remain a reliable Exp3 grasp with the simplest workable end effector. A dexterous hand becomes a required dependency only after it passes local integration and repeatability gates. ## When Does The Research Theme Change? Adding a dexterous hand does not automatically change the current research theme. The theme changes only when task intention, grasp-skill choice, or dexterous manipulation becomes a primary research variable rather than an implementation detail. | System Scope | Theme Decision | System Handling | Status | | ------------------------------------------------------------------------------------------------------------------ | -------------------------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------ | | a dexterous hand executes a small fixed set of grasp primitives | remain robotic grasping | keep the work inside `SAH-BRI-Grasp`; treat the hand as an interchangeable end effector | `verified` as the current project boundary | | the robot selects among grasp primitives, but the experiment still evaluates object selection and grasp completion | remain robotic grasping | evaluate the hand as an Exp3 implementation or follow-up ablation | `inferred` | | the user or robot must distinguish task intention such as pick up, hand over, reposition, or use | expand toward skill-level manipulation | define a separate manipulation study after the grasping baseline | `needs confirmation` | | object-task-skill selection, contact adaptation, or in-hand behavior becomes the main independent variable | change to dexterous manipulation | consider a new system instance and a separate paper claim set | `needs confirmation` | The practical rule is: > A new hand changes the apparatus. A new task-and-skill research question changes the theme. This boundary keeps the first system paper focused while preserving a credible path from grasping to manipulation. ## System Instance Boundary The proposed repository hierarchy is: ```text SAH-BRI framework |-- SAH-BRI-Grasp current system and first paper scope | |-- simple-gripper baseline | `-- dexterous-hand end-effector pilot `-- SAH-BRI-Manip provisional future system name |-- object intention |-- task intention |-- skill selection `-- arm-hand shared autonomy ``` `SAH-BRI-Manip` is a provisional working name only. It is not the current system, an active experiment, or a verified contribution. Promote the name into a real system instance only when all of these conditions are met: * the research task extends beyond single-grasp completion; * task or skill selection is an explicit experimental variable; * a repeatable arm-hand platform and primitive library exist; * a dedicated protocol, baselines, metrics, and failure taxonomy are frozen; * the relevant dexterous-manipulation evidence has entered the local paper workflow. ## First-Paper And Future-Paper Questions | Output | Primary Question | Current Handling | | ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- | | `SAH-BRI-Grasp` / first system paper | Can scene objects become dynamic BCI commands that shared autonomy converts into reliable robotic grasping? | current Exp1-Exp4 claim path | | provisional `SAH-BRI-Manip` / future paper | Can low-bandwidth brain intention supervise a high-dimensional arm-hand system through hierarchical task and skill selection? | exploratory direction; no active manuscript claim | The second question should not be merged into the first paper until the current grasping baseline exists. Otherwise, hardware integration, task semantics, skill arbitration, and contact control would make it unclear which component produced an observed result. ## Hierarchical Dynamic Command Space A dexterous hand makes it possible to test a richer command-space hypothesis: ```text OBJECT: cup TASK: pick up | hand over | reposition SKILL: power grasp | handle grasp | pinch EXECUTION: robot-selected joint and finger trajectory ``` Not every level should be shown to the user. The system should expose an extra BCI choice only when task ambiguity is meaningful and robot confidence is insufficient. | Decision | Preferred Owner | Reason | | --------------------------------------------------------- | ------------------------------------------ | ------------------------------------------------- | | target object | user through SSVEP | semantic intent originates with the user | | execute, cancel, pause, or stop | user through MI or SSVEP plus safety gates | preserves supervisory control | | task choice when ambiguous | user or explicit UI confirmation | task meaning may not be recoverable from geometry | | grasp skill when one option is clearly feasible | robot autonomy | avoids unnecessary BCI selections | | grasp skill when alternatives encode different user goals | shared decision | combines user preference with robot feasibility | | arm and finger joint trajectories | robot controller | too high-dimensional for non-invasive EEG control | Claim status: `inferred`. This hierarchy is a proposed design, not a demonstrated performance result. ## Candidate Grasp Skills The first implementation should use a small discrete skill library rather than general dexterous manipulation: ```text OPEN POWER_GRASP PINCH TRIPOD_GRASP LATERAL_GRASP HANDLE_GRASP RELEASE ``` Each skill needs a machine-readable contract: * eligible object geometry and task context; * hand preshape and closure sequence; * arm approach constraints; * force, current, position, or timeout limits; * success and failure signals; * safe release and recovery behavior. The exact skill set remains `needs confirmation` until a hand, object set, sensing method, and task set are selected. ## Self-Designed Arm Boundary A self-designed arm can provide a reproducible system platform, but hardware construction alone is not yet a scientific contribution. It becomes a stronger output only if the project contributes at least one of the following: * reproducible mechanical, electrical, controller, URDF, and calibration artifacts; * a novel arm-hand coordination or safety method; * measurable cost, payload, repeatability, latency, or task-performance advantages; * a benchmark that other arm-hand systems can reproduce; * evidence that the hardware enables a research question unavailable with a standard platform. Otherwise, the arm should be described conservatively as the experimental apparatus. ## AmazingHand As A First Candidate The [AmazingHand official repository](https://github.com/pollen-robotics/AmazingHand) is an engineering lead for a low-cost first prototype. Its repository currently exposes CAD, BOM, assembly material, and Python/Arduino examples, and states Apache 2.0 licensing for the project software and CC BY 4.0 for the mechanical design. The same repository warns that physical angle variation can arise from printing and assembly, that long and complex prehensile tasks have not yet been validated, and that safer grasping needs smarter behavior based on available actuator feedback. Evidence boundary: * these are external project-repository statements, not local paper-corpus evidence; * license files and the exact selected revision must be reviewed before reuse; * local payload, repeatability, thermal, current, grasp-success, and durability tests remain `needs confirmation`; * AmazingHand should be treated as a candidate platform, not as a pre-validated gripper. ## Integration Gates | Gate | Required Record | Why It Matters | | ----------- | ----------------------------------------------------------------------------- | -------------------------------------------- | | mechanical | wrist adapter, fasteners, mass, center of mass, payload margin, cable routing | prevents overload and unstable motion | | electrical | supply, peak current, grounding, communication bus, fault isolation | separates hand faults from arm and EEG hosts | | model | URDF or equivalent collision and tool-frame model | enables planning and reproducible transforms | | control | command units, limits, update rate, feedback fields, timeout behavior | defines the end-effector runtime contract | | calibration | servo zero, fingertip workspace, arm-hand tool frame, camera transform | links perception to physical contact | | safety | current, temperature, joint, pinch, collision, stop, and release rules | blocks unsafe closure and recovery | | validation | repeated primitive trials over a frozen object set | determines whether the hand can enter Exp3 | All numeric thresholds remain `needs confirmation` until hardware is selected and recorded in `experiments/hardware-inventory.md`. ## Staged Research Route ### Stage 0: Candidate Assessment * compare license, build completeness, payload, sensing, simulation support, and controller access; * select a hand revision and freeze its source revision; * decide whether the self-designed arm has sufficient payload and wrist-interface margin. ### Stage 1: Exp3-Compatible Primitive Grasping * implement `OPEN`, one stable power grasp, one pinch grasp, and `RELEASE`; * use scripted or replayed commands before online EEG; * test repeated static tabletop grasps and failure recovery; * keep the hand interchangeable with a simpler gripper through one end-effector interface. ### Stage 2: Feedback-Aware Shared Autonomy * add position, current, torque, temperature, or tactile feedback where available; * adapt closure and abort behavior to contact and confidence; * log hand failures separately from BCI, perception, planning, and arm failures. ### Stage 3: Hierarchical Intent Study * compare object-only selection against object-plus-task or object-plus-skill selection; * compare automatic skill choice against confidence-triggered user disambiguation; * measure success, decision count, time, workload, correction, and safety blocks. ### Stage 4: Separate Output Only after the earlier stages produce repeatable local evidence should the repository create a dedicated Exp5 protocol or promote a second-paper claim about dexterous shared autonomy. ## Candidate Research Questions | Question | Status | What Would Resolve It | | --------------------------------------------------------------------------------------------------------- | -------------------- | ----------------------------------------------------------- | | Can a low-bandwidth SSVEP-MI interface supervise a high-dimensional arm-hand system through grasp skills? | `needs confirmation` | online comparison against simpler command interfaces | | Does hierarchical object-task-skill selection improve task success without excessive BCI burden? | `needs confirmation` | staged user study with decision-count and workload measures | | When should the robot choose a grasp skill automatically and when should it ask the user? | `needs confirmation` | confidence-aware arbitration experiment | | Can an open-source hand execute a small primitive library repeatably on the selected self-designed arm? | `needs confirmation` | frozen hardware benchmark and failure logs | | Does feedback-aware closure improve grasp reliability and safety over position-only closure? | `needs confirmation` | repeated paired hardware trials | ## Contribution Boundary Potentially publishable after evidence exists: * hierarchical dynamic command-space generation; * skill-level BCI shared autonomy for high-dimensional manipulation; * confidence-aware user disambiguation of grasp tasks or skills; * feedback-aware arm-hand execution with a reproducible benchmark; * an open, reproducible SAH-BRI arm-hand research platform. Insufficient by itself: * mounting an existing hand on a custom arm; * mapping one BCI class directly to one fixed hand pose; * reporting a demo without baselines, repeated trials, or failure taxonomy; * presenting vendor or repository specifications as local performance evidence. ## Documentation Outputs If The Direction Advances Create these only when their prerequisites exist: ```text system/end-effector-abstraction.md system/grasp-skill-library.md system/arm-hand-coordination.md reports/open-dexterous-hand-integration-assessment.md experiments/exp05-grasp-skill-shared-autonomy/ ``` Before adding manuscript-level claims, add relevant user-downloaded papers through the normal ledger, paper-card, evidence-matrix, synthesis, and gap-audit workflow. Do not automatically download dexterous-hand papers.