Chapter 8: Do Not Insist on One Method — Classical + Learned Hybrid Architecture

Overview

Chapter 7 made RL optional optimization over an approved BC/ACT policy, admitted only after a pre-registered value gate. The more important question now is not which learned policy won. It is who approves its proposal on the path to a robot command, and who owns motion when a proposal is late, infeasible, conflicting, or stale.

A hybrid architecture is not a diagram containing many algorithms. It is an execution contract in which a task FSM, policy, planner and IK, constraint projection, contact controller, real-time interface, fallback, human intervention, and independent safety each have inputs, outputs, rates, deadlines, and failure actions. When one component fails, the next state and authority must already be defined.

The RobotClient/PolicyServer example in the Capuano tutorial is a useful map for overlapping inference with action execution ^[12]. Queue throughput is not a real-time guarantee. Without observation timestamps, maximum age, chunk version, watermarks, network jitter, reorder/drop rules, state divergence, safe hold, and reconnection semantics, the robot can execute a smooth action conditioned on an obsolete state.

After reading this chapter... - You can separate task selection, learned proposal, feasibility, contact stabilization, fallback, and safety authority. - You can define a versioned skill API and explicit finite-state machine (FSM). - You can attach timestamps, maximum age, identity, deadlines, queue state, and divergence rules to an asynchronous chunk. - You can reject late, reordered, conflicting, and state-diverged chunks and enter deterministic fallback. - You can distinguish throughput optimization from real-time and safety authority. - You can preserve the downstream contract when #S13 introduces a VLA, world model, or agent upstream.

The experiment question is: A remote PolicyServer returns an insertion-approach chunk late, after RobotClient has crossed into contact using the previous chunk. Should the client drop, trim, replace, or blend the new chunk, and which state and owner decide?

1. Draw the hybrid stack as an authority map

The architecture below is S12 tutorial synthesis. MoveIt move_group, ros2_control, impedance control, and LeRobot asynchronous documentation each establish component boundaries, but no one source standardizes the combined design ^{[9] [15] [1] [19]}. Each component retains platform-specific assumptions and evidence.

task owner / FSM
  selects versioned skill and phase
            ↓
learned proposer ───────────── confidence, chunk, validity
            ↓
feasibility owner ──────────── IK, collision, workspace, rate projection
            ↓
trajectory/contact owner ───── interpolation, impedance/force stabilization
            ↓
real-time/vendor controller ── accepted setpoint, feedback, fault
            ↓
robot and sensors

runtime assurance: age · deadline · divergence · queue · OOD · fallback
independent safety: hardware limits · watchdog · protective stop · E-stop
human authority: approve · intervene · recover · rollback

1.1 Owner–rate–deadline–failure matrix

ROS 2 connects topics, services, actions, and lifecycle, but interface type does not guarantee deadlines or safe transitions ^{[13] [14]}. ros2_control standardizes controller/hardware boundaries, while timing depends on the OS, hardware plugin, and controller implementation ^{[15] [5]}. Record configured, measured, and guaranteed timing separately.

1.2 Versioned skill API and FSM

Each skill request carries skill_name, semantic version, task and phase IDs, preconditions, observation schema, action representation, controller mode, workspace/rate/force limits, deadline, evaluator, allowed fallback, checkpoint, and config hash. An upstream model may request insert_v3; it cannot silently change Cartesian meters into normalized joints or switch impedance to torque mode.

IDLE → VALIDATE → FREE_SPACE → PRE_CONTACT → CONTACT → VERIFY → RETREAT
                 ↘ SAFE_HOLD ↔ HUMAN_RECOVERY ↘ ABORT

Transitions require evidence, not confidence alone. PRE_CONTACT → CONTACT may require pose tolerance, controller-mode acknowledgment, a fresh force signal, and a valid contact envelope. A learned score may request SAFE_HOLD; it cannot authorize a guarded transition.

2. A learned output is a bounded proposal

Policy output a_t^p is a proposal, not a command. A feasibility owner projects it into the state-dependent admissible set \mathcal C(s_t) or rejects it:

$$

a_t^{sent}=\Pi_{\mathcal C(s_t)}(a_t^p),

\qquad d_t=\|a_t^p-a_t^{sent}\|.

$$

Log projection distance, violated constraints, phase, and action age. Repeated large projection means the supervisor is rescuing the policy; success alone is not enough. Collision-free geometry also does not establish controller tracking or contact safety. TrajOpt is an important collision-aware optimization lineage ^[4], but its partial packet evidence does not justify a universal feasibility claim.

2.1 Planner, Servo, and feasibility

MoveIt move_group connects planning-scene state to a controller action interface; it is not the hardware action server ^[9]. Free-space transport can retain a planned trajectory and classical fallback. A learned policy may propose a grasp or local waypoint while the planner checks geometric feasibility.

MoveIt Servo can scale velocity near collisions and singularities, but the current tutorial does not claim certified safety ^[10]. Smoothing plugins require local tests because they may deviate or overshoot. Software collision checks, uncertainty scores, and learned feasibility predictions may trigger hold or fallback; they do not replace force limits, watchdogs, or E-stop authority ^{[10] [16]}. TRANSIC is a learned-correction candidate, not verified safety evidence for this claim ^[7].

2.2 Contact stabilization stays downstream

Even if a policy proposes a Cartesian delta or force target, an impedance or force controller owns interaction dynamics. Hogan and Khatib provide historical formulation lineages ^{[1] [2]}, but their partial locators here do not support a universal gain or stability number.

The ros2_control Joint Trajectory Controller can expose tolerances and action completion, while hold behavior still depends on valid feedback and hardware implementation ^[17]. Topic mode and platform behavior differ. Test controller holds through fault injection on the actual driver/controller or a faithful stub. Platform-specific behavior such as Universal Robots speed scaling requires its own official evidence ^[18].

3. The asynchronous inference contract

LeRobot documentation overlaps RobotClient execution with PolicyServer prediction through an action queue ^[19]. This is a throughput mechanism. The inspected page supplies no hard-real-time or safety guarantee, and queue sizes or chunk thresholds are examples rather than safe defaults.

3.1 Chunk envelope and timing

Every chunk C_k carries:

chunk_id, sequence, policy_checkpoint, config_hash
skill_version, task_phase, controller_mode, calibration_epoch
observation_event_time, observation_arrival_time, clock_domain
inference_start, inference_end, server_send, client_receive
first_action_time, last_action_time, max_observation_age, max_action_age
state_fingerprint, queue_epoch, replacement_policy, fallback_id

An asynchronous interface needs observation/action timestamps, maximum age, chunk identity, watermarks, reorder/drop policy, deadline behavior, and safe fallback. These fields are S12 synthesis motivated by gaps in the inspected async page. A2C2 is a correction candidate, not safety evidence ^{[19] [13] [11]}.

$$

Age(a_{k,j})=t^{exec}_{k,j}-t^{obs}_{k},

\qquad

Slack(a_{k,j})=t^{deadline}_{k,j}-t^{ready}_{k,j}.

$$

An action is expired if age exceeds its phase-specific maximum or slack is negative, even when it belongs to the newest chunk. Add clock-offset uncertainty to conservative age. A remote server must carry synchronized-clock provenance or a measured round-trip bound rather than comparing arbitrary wall clocks.

3.2 Queue rules

• A low watermark requests inference early enough for measured p95 tails.
• A high watermark limits old-action accumulation; it does not authorize arbitrary dropping.
• A reordered sequence from an old queue epoch is rejected; reconnection purges old epochs.
• Duplicate ID and payload hash are idempotently ignored.
• A late chunk may have an expired prefix; trimming is allowed only under a phase-specific tested rule.
• Phase, controller, calibration, or skill conflicts reject the chunk.
• Excess state divergence rejects even time-valid actions.

Watermarks manage throughput, not safety. Network loss does not answer whether to drain a queue or hold. Task phase and action age do. A contact transition may purge remaining free-space actions and hand authority to a validated contact controller.

4. Worked stale-chunk trace

These relative times explain the contract; they are not hardware defaults.

A newest-wins implementation would execute C41 after contact and send pre-contact displacement. The proper reason is not merely LATE; it is PHASE_MISMATCH + STATE_DIVERGED + OLD_QUEUE_EPOCH. This trace tests interface correctness, not model quality.

4.1 Four treatments for a late chunk

Run feasibility again after trimming or blending. The mean of two feasible actions is not necessarily safe as a trajectory. Trimming must not delete a gripper event or phase transition.

4.2 Reconnection semantics

On disconnect, the client enters DEGRADED, issues a new queue epoch, drains or purges according to phase, and transfers authority to fallback. Reconnection requires a handshake over current skill, phase, controller, calibration, and checkpoint allowlist. A chunk from the old session is invalid even if its sequence is numerically larger.

5. Fallback state machine

RUNNING
  ├─ stale/late/reorder ─→ DEGRADED
  ├─ OOD/divergence ─────→ SAFE_HOLD
  ├─ feasibility reject ─→ REPLAN_OR_RETREAT
  ├─ contact anomaly ────→ CONTACT_FALLBACK
  ├─ watchdog/fault ─────→ CONTROLLER_STOP
  └─ human request ──────→ HUMAN_RECOVERY

DEGRADED → recovered handshake → VALIDATE → RUNNING
any state → E_STOP (independent authority)

Fallback needs trigger, debounce, owner, maximum transition latency, queue action, controller command, recovery precondition, and log. An OOD score may request SAFE_HOLD; it cannot authorize unsafe motion.

5.1 Failure diagnosis

6. Approve one assembly cycle by owner

Divide the tabletop task into acquire → grasp → transport → pre-contact → insert → verify → retreat, then select the most verifiable default for each phase. Acquire and grasp may accept a perception-conditioned learned proposal. Collision-free transport defaults to a MoveIt trajectory and trajectory controller. ACT or diffusion may propose bounded Cartesian deltas during pre-contact. After contact onset, the Chapter 3 impedance or force controller owns stabilization. An independent physical evaluator and classical retreat close the cycle.

This design is more useful than saying that classical and learned methods are “combined” because each rollback is explicit. If a learned grasp pose fails feasibility, request another candidate or return to a scripted grasp. If trajectory planning misses its deadline, do not move and replan. If a pre-contact chunk is stale, hold before contact. A contact anomaly selects force-aware retreat before another policy attempt.

6.1 Phase contract card

The useful column is approval owner, not the method name. A future VLA may propose a better grasp while IK, collision, gripper, and controller contracts remain. A more expressive contact policy does not replace the force monitor or E-stop.

6.2 Build a phase timing budget

Decompose the pre-contact end-to-end budget as

$$

B_{phase}=L_{sense}+L_{transport}^{obs}+L_{pre}+L_{infer}

+L_{transport}^{act}+L_{queue}+L_{project}+L_{controller}.

$$

Do not validate only a sum of means. Retain p50, p95, maximum, and correlation for every component. Camera backlog and network jitter may coincide and create a tail longer than a naive sum of percentiles. Use measured end-to-end traces to set observation/action age limits and component budgets for diagnosis.

Suppose an illustrative pre-contact maximum age is 120 ms. Observation age p95 is 30 ms, preprocessing 10 ms, inference 45 ms, network 12 ms, queue 15 ms, and projection/controller handoff 8 ms. The total is already 120 ms. Zero margin is a design failure rather than a nominal pass: one additional millisecond causes rejection. Request earlier, move inference locally, reduce model tail, or revalidate the execution horizon. These are arithmetic examples, not hardware defaults.

6.3 Separate policy updates from configuration updates

Version more than weights. The skill API, observation processors, queue thresholds, age limits, divergence metric, projection, controller mode, and fallback table form one compatibility set. Repeat shadow regression after a change in camera key/order, calibration, normalization, action dimension/unit/frame, chunk horizon, controller mode/rate/firmware, timeout/watermark/replacement/aggregation, workspace/force/collision envelope, evaluator, FSM guard, or authority transition.

The deployment manifest stores compatible tuples in an allowlist. A new server checkpoint cannot enter the queue until RobotClient checks local allowlist, signature or hash, schema, and controller compatibility. Client-side bounds and independent safety must survive a compromised or misconfigured server.

Compatibility handshake and degraded-mode acceptance test

Treat the allowlist check as a protocol, not a startup assertion. Before accepting the first chunk, the client sends its skill API, observation/action schema, calibration epoch, controller mode and rate, queue epoch, and supported reason-code table. The server returns the checkpoint and processor hashes, expected tensor keys and shapes, action frame and units, chunk horizon, and compatible protocol range. Both sides derive a compatibility fingerprint from those fields. A mismatch rejects the session before any proposal reaches the execution queue; reconnecting with a new epoch does not waive the check.

Test the handshake with a small matrix that changes one field at a time: compatible tuple, old checkpoint, reordered observation keys, stale calibration, wrong action unit, unsupported controller mode, unknown reason code, and server restart with an old queue epoch. The expected result is either ACCEPT with the exact fingerprint or a bounded rejection code with an empty queue. “Connected” is not a passing result. The replay artifact must show the offered tuple, local allowlist version, decision, queue action, fallback state, and operator-visible reason.

Degraded mode also needs an explicit contract. If logging, visualization, or a nonessential modality is unavailable, the manifest states whether the phase may continue, at what reduced envelope, and for how long. Loss of a required observation, clock validity, controller feedback, or compatibility evidence remains fail-closed. Exercise these cases on deterministic replay and a hardware-interface stub before shadow deployment. This keeps graceful degradation from becoming an undocumented bypass around the same compatibility gate that protects normal operation.

6.4 Promotion workflow

1. Schema tests: serialization, version mismatch, units, and clock arithmetic.
2. State-machine model tests: illegal transitions, simultaneous triggers, debounce, and recovery reachability.
3. Deterministic replay: reproduce queue decisions from recorded observations and network traces.
4. Simulation fault injection: combine collision, contact, delay, drop, disconnect, and divergence.
5. Hardware-interface stub: verify actual controller messages and feedback semantics without motion.
6. Shadow: the approved stack executes while candidate queue, projection, and fallback only log.
7. Bounded trial: execute only under a signed envelope and independent stop authority.

Each stage distinguishes pass from not exercised. If simulation cannot represent protective-stop recovery, that branch is untested, not passed. Never appoint an untested branch as production fallback.

6.5 Observability comes before fallback claims

Join observations, requests, inference, chunks, projection, controller acknowledgments, robot feedback, FSM transitions, and safety events under one cycle_id. Preserve event and arrival times instead of keeping only a wall-clock dashboard. Minimum metrics include proposal and rejection count by phase, projection distance, action age, deadline misses, queue depth, fallback transition latency, recovery outcome, and human takeover latency.

Logging failure is itself a fault. If the controller moves while the system loses the sent action or authority transition, the evaluator cannot promote that cycle as success. If privacy or bandwidth prevents retaining an image, keep its frame hash, calibration identity, timestamp, and missing-data reason. A fallback without observability cannot be shown to have executed as designed.

Monitor telemetry backpressure as well. Unbounded labels such as raw exception text or per-frame identifiers can overwhelm telemetry and perturb the runtime being observed. Define bounded reason codes and route heavy traces to an asynchronous recorder that cannot block the controller. If the recorder falls behind, expose the gap, preserve the safety event locally, and enter the configured degraded mode rather than silently dropping evidence.

The promotion report distinguishes detection latency, decision latency, controller-acceptance latency, and physical settling time. One total “fallback latency” hides whether the network, runtime-assurance process, controller, or robot dominated the response. This decomposition becomes a Chapter 9 fault-injection artifact.

7. Manufacturing Cell Checkpoint

Required architecture artifacts are a versioned skill API, FSM transition table, owner–rate–deadline–failure matrix, clock map, feasibility/projection log, controller hold/retreat fault evidence, and fallback/human-authority state machine.

Required async artifacts are chunk schema and hashes; p50/p95/max observation age, inference, jitter, and queue wait; watermark hysteresis; stale/late/reorder/duplicate/phase/divergence tests; reconnection and old-session purge; and phase-specific owners for hold, retreat, and planner fallback.

Promotion checklist

• [ ] Learned output is a bounded proposal, never torque or safety authority.
• [ ] Task, feasibility, contact, fallback, and safety owners are separate.
• [ ] Every chunk has timestamps, maximum age, versions, epoch, and phase.
• [ ] Late, conflicting, and diverged chunks are deterministically rejected.
• [ ] Queue underflow/overflow cannot create an indefinite last-action hold.
• [ ] Trimmed or blended actions pass feasibility again.
• [ ] Controller hold and fallback are tested on the actual platform or stub.
• [ ] Watchdog, E-stop, and protective stop remain outside policy.
• [ ] Reconnection cannot resurrect old chunks.
• [ ] Simulation, shadow, and bounded-hardware evidence remain distinct.

8. A bounded Codex implementation prompt

Goal
- Implement and test the hybrid skill/runtime contract for asynchronous
  chunk inference without sending commands to hardware.

Context
- Read the skill API, FSM, observation/action schema, controller contract,
  feasibility constraints, checkpoint allowlist, fallback table, and clock map.

Constraints
- Separate task selection, policy proposal, feasibility projection,
  contact control, runtime fallback, human intervention, and safety authority.
- Add chunk ID/sequence/epoch, policy/config/skill versions, phase/controller mode,
  event/arrival/inference/send/receive/action times, maximum age, fingerprint,
  watermarks, replacement rule, and fallback ID.
- Reject stale, reordered, duplicate, phase-conflicting, calibration-mismatched,
  and state-diverged chunks with explicit reason codes.
- Re-run feasibility after trim, replacement, aggregation, or blending.
- Treat queue optimization as throughput only. Never let an LLM, VLA, policy,
  confidence score, or remote server own torque, force limits, watchdog, or E-stop.

Done when
- Unit/property tests cover time arithmetic, clock uncertainty, idempotence,
  atomic queue replacement, epoch purge, and state-machine transitions.
- A deterministic simulator/stub reproduces the worked stale-chunk trace.
- Fault injection covers delay, jitter, drop, reorder, duplicate, disconnect,
  phase change, divergence, controller rejection, and human takeover.
- Logs show proposal/projected/sent actions, queue state, reason, owner, fallback,
  and recovery. Build a shadow-test card; execute no hardware motion.

Safety
- External safety inputs are read-only to this implementation. Stop at a
  human-reviewed bounded trial card with independent stop authority and rollback.

9. Stable interface for #S13

Keeping downstream action and safety contracts explicit when #S13 replaces the upstream proposer with a VLA, world model, or agent is an editorial architecture objective, not yet a scientific performance claim ^{[12] [6] [8]}.

#S13 inherits versioned skill preconditions and phase; observation provenance, masks, timestamps, and age; bounded action representation and controller mode; proposal/projected/sent distinctions; chunk identity, queue epoch, deadline, divergence, and reconnect behavior; the limited holds/fallbacks an uncertainty score may request; independent evaluator, watchdog, collision/force, E-stop, and human owners; and promotion evidence.

Language-model programs illustrate an upstream possibility ^[6], but generated text or code never owns torque or safety state. Generalist pretraining, cross-embodiment transfer, grounding, world-model planning, and memory/tool use are reverified from originals in #S13.

Relation to Prior Surveys

#S11 established independent safety authority and ROS 2/driver commissioning. This chapter does not repeat that material. It attaches the Chapter 4–7 data and policy artifacts to the inherited boundary without copying prose or numbers. Public links wait until #S11 is release-ready.

What to Learn Next

Chapter 9 executes this architecture as one tabletop-assembly runbook: classical baseline, dataset, BC/ACT, generative option, optional RL, asynchronous serving, shadow, and bounded trial. It receives the skill API, FSM, timing/queue schema, fallback table, safety ownership, and fault-injection tests from this chapter.

References

1. Hogan, N. (1985). Impedance Control: An Approach to Manipulation, Part I—Theory. Journal of Dynamic Systems, Measurement, and Control. DOI: 10.1115/1.3140702.
2. Khatib, O. (1987). A Unified Approach for Motion and Force Control of Robot Manipulators. IEEE Journal on Robotics and Automation. DOI: 10.1109/JRA.1987.1087068.
3. Bruyninckx, H. (2001). Open Robot Control Software: The OROCOS Project. IEEE ICRA. DOI: 10.1109/ROBOT.2001.933002.
4. Schulman, J., et al. (2014). Motion Planning with Sequential Convex Optimization and Convex Collision Checking. IJRR. DOI: 10.1177/0278364914528132.
5. Chitta, S., et al. (2017). ros_control: A Generic and Simple Control Framework for ROS. JOSS. DOI: 10.21105/joss.00456.
6. Liang, J., et al. (2023). Code as Policies: Language Model Programs for Embodied Control. ICRA. arXiv:2209.07753.
7. Jiang, Y., et al. (2024). TRANSIC: Sim-to-Real Policy Transfer by Learning from Online Correction. CoRL.
8. Octo Model Team (2024). Octo: An Open-Source Generalist Robot Policy. arXiv:2405.12213.
9. MoveIt / PickNik (2025a). MoveIt 2 move_group Architecture. Official documentation, accessed 2026-07-15.
10. MoveIt / PickNik (2025b). MoveIt Servo Realtime Teleoperation Tutorial. Official documentation, accessed 2026-07-15.
11. Sendai, K., et al. (2025). Leave No Observation Behind: Real-time Correction for VLA Action Chunks. arXiv:2509.23224.
12. Capuano, F., et al. (2025). Robot Learning: A Tutorial. arXiv:2510.12403v1. DOI: 10.48550/arXiv.2510.12403.
13. Open Robotics (2026a). ROS 2 Jazzy Interfaces: Topics, Services, and Actions. Official documentation, accessed 2026-07-15.
14. Open Robotics (2026b). ROS 2 Jazzy Managed Node Lifecycle. Official documentation, accessed 2026-07-15.
15. ros-controls (2026a). ros2_control Jazzy Architecture. Official documentation, accessed 2026-07-15.
16. ros-controls (2026b). Controller Manager Monitoring and Limits. Official documentation, accessed 2026-07-15.
17. ros-controls (2026c). Joint Trajectory Controller Jazzy. Official documentation, accessed 2026-07-15.
18. Universal Robots (2026). UR ROS 2 Controllers and Speed Scaling. Official documentation, accessed 2026-07-15.
19. Hugging Face (2026). LeRobot Asynchronous Inference. Official documentation, accessed 2026-07-15.
20. Oussama Khatib (1986). Real-Time Obstacle Avoidance for Manipulators and Mobile Robots. Annotated primary reading. DOI: 10.1177/027836498600500106. — Role: primary reading for hybrid interfaces, fallback, and runtime ownership. Limitation: Performance depends on geometry, initialization, objectives, and model fidelity; feasibility does not imply controller tracking.
21. Sean Quinlan & Oussama Khatib (1993). Elastic Bands: Connecting Path Planning and Control. Annotated primary reading. DOI: 10.1109/robot.1993.292042. — Role: primary reading for hybrid interfaces, fallback, and runtime ownership. Limitation: Performance depends on geometry, initialization, objectives, and model fidelity; feasibility does not imply controller tracking.
22. Alin Albu-Schäffer et al. (2003). Cartesian Impedance Control of Redundant Robots: Recent Results with the DLR-Light-Weight-Arms. Annotated primary reading. DOI: 10.1109/robot.2003.1242285. — Role: primary reading for hybrid interfaces, fallback, and runtime ownership. Limitation: Delay, sampling, saturation, filtering, environment stiffness, and hardware interfaces bound the reported behavior.
23. Luis Sentis & Oussama Khatib (2008). Robot Manipulator Control Using Generalized Operational Space. Annotated primary reading. canonical URL. — Role: primary reading for hybrid interfaces, fallback, and runtime ownership. Limitation: The assumptions and evaluation setup are source-specific; current implementation claims require maintained official evidence.
24. Rosen Diankov (2010). OpenRAVE: A Planning Architecture for Autonomous Robotics. Annotated primary reading. canonical URL. — Role: primary reading for hybrid interfaces, fallback, and runtime ownership. Limitation: Performance depends on geometry, initialization, objectives, and model fidelity; feasibility does not imply controller tracking.
25. Igor Mordatch et al. (2012). Discovery of Complex Behaviors through Contact-Invariant Optimization. Annotated primary reading. canonical URL. — Role: primary reading for hybrid interfaces, fallback, and runtime ownership. Limitation: Delay, sampling, saturation, filtering, environment stiffness, and hardware interfaces bound the reported behavior.
26. Tully Foote (2013). tf: The transform library. Annotated primary reading. DOI: 10.1109/TePRA.2013.6556373. — Role: primary reading for hybrid interfaces, fallback, and runtime ownership. Limitation: A connected TF tree can still encode wrong axes, units, optical frames, or stale calibration.
27. Aude Billard & Danica Kragic (2019). Trends and Challenges in Robot Manipulation. Annotated primary reading. DOI: 10.1126/science.aat8414. — Role: primary reading for hybrid interfaces, fallback, and runtime ownership. Limitation: The assumptions and evaluation setup are source-specific; current implementation claims require maintained official evidence.
28. Oliver Kroemer et al. (2021). A Review of Robot Learning for Manipulation: Challenges, Representations, and Algorithms. Annotated primary reading. arXiv:1907.03146. — Role: primary reading for hybrid interfaces, fallback, and runtime ownership. Limitation: The assumptions and evaluation setup are source-specific; current implementation claims require maintained official evidence.
29. Ajay Mandlekar et al. (2023). Human-in-the-Loop Task and Motion Planning for Imitation Learning. Annotated primary reading. canonical URL. — Role: primary reading for hybrid interfaces, fallback, and runtime ownership. Limitation: Performance depends on geometry, initialization, objectives, and model fidelity; feasibility does not imply controller tracking.
30. Raunaq Bhirangi et al. (2024). AnySkin: Plug-and-play Skin Sensing for Robotic Touch. Annotated primary reading. arXiv:2409.08276. — Role: primary reading for hybrid interfaces, fallback, and runtime ownership. Limitation: Platform, task, dataset, and evaluation assumptions must be checked in the primary paper before transferring a result.
31. Li, others (2024). Evaluating Real-World Robot Manipulation Policies in Simulation. Annotated primary reading. arXiv:2405.05941. — Role: primary reading for hybrid interfaces, fallback, and runtime ownership. Limitation: Platform, task, dataset, and evaluation assumptions must be checked in the primary paper before transferring a result.
32. Marius Memmel et al. (2024). ASID: Active Exploration for System Identification in Robotic Manipulation. Annotated primary reading. arXiv:2404.12308. — Role: primary reading for hybrid interfaces, fallback, and runtime ownership. Limitation: Excitation policy can be task- and simulator-specific
33. Zhang et al. (2024). Online Payload Identification by Parameter Difference for Industrial Robots. Annotated primary reading. DOI: 10.1017/s026357472400105x. — Role: primary reading for hybrid interfaces, fallback, and runtime ownership. Limitation: Assumes robot-base parameter changes are separable from payload
34. DREAM authors (2025). DREAM: Differentiable Real-to-Sim-to-Real Engine for Robotic Manipulation. RSS 2025 Dexterous Manipulation Workshop annotated primary reading. canonical OpenReview record. — Role: primary reading for hybrid interfaces, fallback, and runtime ownership. Limitation: Workshop-scale evidence
35. Marco Iannotta et al. (2026). Can Context Bridge the Reality Gap?. Annotated primary reading. DOI: 10.1016/j.robot.2026.105594. — Role: primary reading for hybrid interfaces, fallback, and runtime ownership. Limitation: One pushing task cannot establish universal context adaptation