# Paper Draft: Method

> Generated from repository source files. Do not edit this page directly; edit the source file listed below and rerun `vp run docs:generate`.

> Source: `paper/sections/03-method.md`

## Method

Status: `interface skeleton expanded`

The method section should describe the `SAH-BRI-Grasp` system architecture as a proposed system design. It can specify modules, interfaces, state transitions, and safety gates, but thresholds and performance expectations remain `needs confirmation` until hardware and pilot experiments exist.

## System Overview

`SAH-BRI-Grasp` instantiates the broader `SAH-BRI` framework for robotic grasping. The system receives visual input from an RGB or RGB-D camera, detects objects in the scene, converts stable detections into selectable candidates, binds those candidates to SSVEP stimuli, decodes SSVEP and MI signals, fuses intent evidence in a state machine, and delegates low-level planning and execution to robot autonomy.

```text
RGB/RGB-D camera
  -> object detector
  -> candidate manager
  -> candidate freeze
  -> SSVEP stimulus binding
  -> EEG acquisition
  -> SSVEP target decoding
  -> MI mode decoding
  -> decision fusion
  -> robot planning
  -> approach and grasp execution
  -> verification and recovery
```

Implementation-facing specifications are maintained in:

* `system/runtime-interfaces.md` for module records and message fields;
* `system/state-machine.md` for state, event, guard, action, safety, and recovery logic.

These files define interface contracts only. They do not validate runtime performance.

## Perception And Candidate Manager

The perception module takes image frames and returns object candidates:

| Field | Description | Status |
| --- | --- | --- |
| `bbox` | image-space object location | inferred from `YOLO-001` |
| `class` | object category label | inferred from `YOLO-001` |
| `confidence` | detector confidence | inferred from `YOLO-001` |
| `timestamp` | frame time | system requirement |
| `track_id` | persistent candidate identity | needs confirmation |
| `stability_score` | jitter/loss estimate | needs confirmation |

The candidate manager should filter, track, and freeze candidates before SSVEP stimulation. The freeze step is required because moving or jittering target boxes may degrade SSVEP decoding; the exact freeze duration remains a pilot parameter.

Runtime records:

* `Vision Frame`;
* `Object Detection`;
* `Candidate`;
* `Candidate Freeze Set`;
* `Stimulus Binding`.

These records are specified in `system/runtime-interfaces.md`.

## SSVEP Target Binding

Each frozen candidate is assigned a visual stimulation code. Based on `SSVEP-001`, `SSVEP-003`, and `SSVEP-004`, frequency tagging, FBCCA, and TRCA are plausible decoding baselines. However, this transfer from fixed speller cells to object boxes is an inferred design choice.

Planned decoder options:

| Decoder | Evidence | Role |
| --- | --- | --- |
| FBCCA | `SSVEP-003` | first baseline for multi-target scene selection |
| TRCA / ensemble TRCA | `SSVEP-004` | calibrated high-speed decoder candidate |
| CCA-family baseline | P1/P2 pending | comparator |

Runtime records:

* `EEG Window`;
* `Stimulus Binding`;
* `SSVEP Decision`.

The ITR formula candidate and the requirement to report raw-window and practical-selection timing are specified in `experiments/analysis-plan.md`.

## MI Mode Decoder

MI is scoped as a mode-level control channel rather than a dense arm-motion controller. `MI-005` supports this boundary by showing noninvasive MI robotic grasping through decomposed low-dimensional control, while not establishing fluid 3D continuous control.

Candidate MI command set:

| Command | Intended Role | Status |
| --- | --- | --- |
| `confirm` | approve selected target or planned action | inferred |
| `cancel` | reject target or return to selection | inferred |
| `pause` / `stop` | interrupt robot execution | inferred |
| `rest` / no-control | prevent false activation | needs confirmation |

Runtime records:

* `EEG Window`;
* `MI Decision`.

No-control rejection and false-activation thresholds must be frozen before online use.

## Decision Fusion State Machine

The decision fusion layer combines visual candidate confidence, SSVEP target evidence, MI mode evidence, and robot-side feasibility checks. The implementation-facing state machine is defined in `system/state-machine.md`.

Nominal flow:

```text
Idle
-> SceneScan
-> CandidateGeneration
-> CandidateFreeze
-> TargetSelection
-> TargetLocked
-> SelectionConfirmation
-> ApproachPlanning
-> ApproachExecution
-> GraspPointConfirmation
-> GraspExecution
-> Verify
-> Success
```

Exception states:

```text
Cancel
Pause
TargetLost
LowConfidence
CollisionRisk
Recovery
EmergencyStop
```

`SA-001` and `SA-002` support using shared autonomy under uncertain goals and confidence-dependent arbitration. The system should therefore avoid aggressive robot assistance when intent confidence is weak or conflicting.

Runtime records:

* `Fused Intent`;
* `Safety Gate Result`.

Every state transition should preserve the source records, guard result, destination state, and rejection or failure reason.

## Robot Planning And Grasp Execution

The robot side should not treat YOLO detection as grasp execution. `GRASP-001` supports the boundary that grasping requires candidate generation, ranking, reachability filtering, and robust execution. The exact grasp method is not yet fixed.

Calibration item:

* `GRASP-006` can now be cited for classical eye-on-hand calibration rationale after OCR recovery.
* A protocol skeleton exists at `experiments/exp03-closed-loop-grasping/hand-eye-calibration.md`.
* Project-specific camera, robot, calibration target, solver, station count, and acceptance metric remain `needs confirmation`.

Runtime records:

* `Robot Plan`;
* `Robot Execution`;
* `Verification Result`.

Physical execution requires a valid calibration record, transform convention, safety gates, and non-contact dry-run verification.

## Safety Gates

| Gate | Rule | Evidence Status |
| --- | --- | --- |
| Candidate confidence | detector confidence must exceed a threshold | needs confirmation |
| Candidate stability | target boxes must remain stable before freeze | needs confirmation |
| SSVEP selection | require decoder confidence and temporal consistency | inferred |
| MI override | cancel/stop should override confirm/execute | inferred |
| Planning feasibility | target pose, reachability, collision, transform checks | inferred |
| Recovery | target loss or low confidence routes to Pause/Recovery/EStop | inferred |

## Method Writing Boundary

This method section can define architecture and interface contracts. It must not claim validated timing, accuracy, grasp success, or safety rates before experiments.