Sub-Millisecond Reflexes for Continuous Physical Human-Robot Interaction

I. INTRODUCTION

• Dynamic, unpredictable homes make unforeseen collisions inevitable,,, requiring torque-controlled systems capable of rapid, low-latency reactions,; domestic task phases impose conflicting objectives, so control must switch dynamically and instantaneously,,.These objectives include accurate free-space motion, compliant interaction, force regulation, and safety-oriented recovery.Source: §I · p. 1
• The proposed ROS 2-compatible architecture enables sub-millisecond controller switching for smooth, continuous task execution.It is designed to work with existing ROS 2 ecosystems.Source: §I · p. 2
• A reflex engine reacts to contact hazards, joint limits, and excessive velocities before manufacturer safety stops are triggered.The engine builds on the proposed switching architecture.Source: §I · p. 2
• Seamless transitions between control behaviours support continuous multistage manipulation without traditional stop-to-switch interruptions..Source: §I · p. 2
• Switching latencies below 0.1 ms, hazard mitigation, and uninterrupted task execution were demonstrated on a physical Franka Robotics manipulator.The introduction reports empirical validation of the controller on the manipulator.Source: §I · p. 2

A. High-Frequency Torque Control

• Early force/torque control supported 60 Hz and 120 Hz, whereas current standards such as ISO 10218 require 1 kHz control and measurement to detect collisions and minimize injury risks.At 60 Hz and 120 Hz, systems could not detect oscillations around 280 Hz; 1 kHz torque loops also enable Lagrangian modelling that treats joints as ideal torque sources.Source: A. High-Frequency Torque Control · p. 2

B. Reflex Behaviours

• A continuous, deterministic 1 kHz torque-control loop supports collision detection by estimating external contact wrenches through proprioceptive observers,.Safe physical interaction also requires a structured control response tailored to the collision’s physical evolution.Source: B. Reflex Behaviours · p. 2
• Collision evolution is categorized into pre-collision, transient Impact Phase I, quasi-static Impact Phase II, and post-collision phases.Impact Phase I lasts 10–20 ms and is governed by structural inertia, so feedback cannot attenuate initial peak forces,.Source: B. Reflex Behaviours · p. 2
• Because feedback cannot influence Impact Phase I, reflex behaviours target later collision stages, including residual crushing forces, reaction termination, secondary hazards, and task recovery,,,.Pre-collision measures such as velocity scaling and posture optimization bound kinetic energy before contact.Source: B. Reflex Behaviours · p. 2
• Reflexes are classified as task-preserving, task-relaxing, or task-abandoning: they adjust timing along the nominal path, allow temporary path shifts, or suspend tracking at safety limits.Source: B. Reflex Behaviours · p. 2
• Reflex implementation has largely been confined to proprietary real-time frameworks such as DLR’s aRD/Beasty, and ArmarX-RT, which lack generalizability and open-source accessibility.Compatibility with modern open-source middleware is described as desirable for broader robotics-community adoption.Source: B. Reflex Behaviours · p. 2
• Monitoring and recording frameworks support analysis and reconstruction of safety-critical interactions,, while this work focuses on online low-latency detection, reflex activation, and recovery.Source: B. Reflex Behaviours · p. 2

C. Existing Robotics Middlewares

• ROS 2 composition and intra-process communication provide stable microsecond-level latencies of approximately 40 µs, but standard distributed configurations face quadratic memory growth and timing jitter.The cited sources attribute memory growth to DDS participant discovery and latency or jitter to serialization overhead and default executor scheduling,.Source: C. Existing Robotics Middlewares · p. 2
• Standard ros2_control’s stop-to-switch transitions block the real-time loop, while multipanda ros2’s average switching delay of approximately 2 ms still misses strict collision-detection requirements.Predefined transition zones can be nearly nonexistent in contact-rich pHRI tasks, making controller blending potentially dangerous.Source: C. Existing Robotics Middlewares · p. 2
• Custom controllers such as those for DLR’s Rollin’ Justin and OROCOS toolkits, achieve deterministic execution but lack the modularity and adaptability of open-source ecosystems.The passages describe this as a trade-off between general-purpose middleware flexibility and platform-specific determinism,.Source: C. Existing Robotics Middlewares · pp. 2–3

A. Multimode Controller Architecture

• The MC builds on open-source multipanda ros2 and integrates into ROS 2 as a standard ros2_control controller.The framework provides native ROS 2 interfaces for coordinated control of multiple robots from a single process.Source: A. Multimode Controller Architecture · p. 3
• Rather than compute a control law itself, the MC supervises configured controllets that calculate torque commands and hold exclusive runtime ownership of each physical motor.Users can configure an arbitrary number of controllets, with no more than one owning any motor at a time.Source: A. Multimode Controller Architecture · p. 3
• The MC avoids runtime allocations and unnecessary copying by giving controllets direct references to shared command and robot-state data.Controllets are constructed with C++ move operators during initialization, providing real-time access to temporally consistent robot state and torque-command data.Source: A. Multimode Controller Architecture · p. 3

B. Optimization for Sub-Millisecond Behaviour Switching

• Runtime controllet switching originally took approximately 2 ms, despite the 1 kHz deterministic sampling requirement for safe pHRI,,.The 1 kHz requirement and original switching delay are stated in the optimization section.Source: B. Optimization for Sub-Millisecond… · p. 3
• Profiling attributed the multi-millisecond delay to runtime creation of ROS 2 communication entities, including non-deterministic DDS resource initialization.These operations can trigger heap allocation, page faults, middleware locks, node-graph updates, and discovery, causing jitter, blocking, or missed deadlines.Source: B. Optimization for Sub-Millisecond… · p. 3
• Pre-initializing middleware endpoints and memory reduces real-time switching to a lock-free pointer reassignment between controllets sharing robot state and command data.The transition requires no context switches, system calls, or middleware intervention, preserving the 1 kHz control cycle.Source: B. Optimization for Sub-Millisecond… · p. 3

C. Reflex Behaviours

• Through controllet switching, the engine intercepts external contact forces, joint kinematic limits, and excessive velocities before manufacturer thresholds are reached, providing compliant collision mitigation, object-affordance preservation, and seamless haptic task recovery.Source: C. Reflex Behaviours · p. 4

1) Hazard Detection and Interception

• At every 1 kHz cycle, hazard detection evaluates each joint’s position, velocity, and torque against buffered safety boundaries.The passage defines these checks for each joint i across the robot’s degrees of freedom.Source: 1) Hazard Detection and Interception · p. 4
• Operational-space hazard detection estimates the contact wrench at the point of interest, typically the end-effector, and checks absolute force and moment magnitudes with buffers.The wrench is estimated from external torque using the Jacobian pseudoinverse.Source: 1) Hazard Detection and Interception · p. 4

2) Reflex State Machine

• The state machine evaluates NORMAL, REFLEX, WAIT FOR RECOVERY, and RECOVERY states within the 1 kHz execution loop.The state machine is visualized in Fig. 3.Source: 2) Reflex State Machine · p. 4, Figure 3 · p. 4
• Safety parameters, threshold modes, buffer margins, and reflex behaviours are defined in ROS 2 YAML files for per-application tuning without recompilation.After the hazard is cleared, the desired operation can continue as before.Source: 2) Reflex State Machine · p. 4
• A haptic gesture with ∥fext∥> 10 N triggers recovery without manual computer commands.The gesture was implemented to support recovery during program execution.Source: 2) Reflex State Machine · p. 4

• The Stop Reflex freezes the manipulator at the time of hazard detection q(tcd).Source: 3) Available Reflex Behaviours · p. 4
• The Admittance Reflex maps measured external torques to reference joint velocities, guiding compliant evasive motion along interaction forces.It uses a proportional gain α.Source: 3) Available Reflex Behaviours · p. 4
• Joint Retraction displaces the target joint configuration along the negative joint-torque vector, scaled by Cartesian bounds δ = 0.05 m via the manipulator Jacobian.This actively relieves joint-level contact stresses.Source: 3) Available Reflex Behaviours · p. 4
• Cartesian Retraction moves the target along the negative external contact-force vector by distance γ while maintaining fixed orientation.Fixed orientation prevents object tilting and secondary hazards.Source: 3) Available Reflex Behaviours · p. 4
• The Zero-G Reflex commands pure gravity compensation to eliminate residual contact forces and prevent severe human clamping in constrained collision scenarios.Source: 3) Available Reflex Behaviours · p. 4

IV. EXPERIMENTAL PROCEDURE

• The experiments used a Franka Panda manipulator controlled by an ASRock mini-PC with 32 GB of DDR5-4800 MHz RAM and the multipanda ROS 2 framework as the real-time backbone.Source: §IV · p. 4
• The validation comprised three phases: quantifying control-switching delay, evaluating reactive reflex behaviours, and executing a multi-stage task against the state of the art.Source: §IV · p. 4

A. Control Behaviour Switching Delay

• Switching latency was benchmarked across five control behaviours in three configurations.Source: A. Control Behaviour Switching Delay · p. 4
• The baseline ros2_control configuration measured lifecycle transitions between active and inactive states, with all controllers loaded and configured before the experiment.Source: A. Control Behaviour Switching Delay · p. 5
• The original multimode-controller configuration used the multipanda ROS 2 framework’s default controllet switching.Source: A. Control Behaviour Switching Delay · p. 5
• The improved multimode-controller configuration used optimized software design to minimize external delays at runtime.Source: A. Control Behaviour Switching Delay · p. 5
• Each configuration was recorded for 100 switches, with delay measured from switch-request initiation until new command values first appeared in the internal libfranka control loop.Cross-correlation between the recorded datasets was used to identify each configuration’s temporal delay.Source: A. Control Behaviour Switching Delay · p. 5

B. Reflex Behaviours

• Joint position and velocity tests drove individual joints toward hardware limits, with safety margins of 0.2 rad and 0.1 rad/s, respectively.The position test used a stiff impedance controller at 75% of hardware speed and ran 10 times for each of seven joints.Source: B. Reflex Behaviours · p. 5
• Position and velocity limit tests used stop reflexes with soft joint impedance, while contact tests used a Zero-G response to unexpected collisions.The soft impedance gains were K1−4 = 200 N/m and K5−7 = 100 N/m.Source: B. Reflex Behaviours · p. 5
• Contact detection was tested against a rigid surface at approach speeds of 0.09–0.26 m/s, with a 15 N force threshold across three configurations and 10 repetitions each.The tests used a Cartesian impedance controller with K = 400 N/m.Source: B. Reflex Behaviours · p. 5

C. Multistage Task Execution

• The cleaning task’s pick-and-place phase moved objects quickly and precisely using a fast velocity controller.The task required switching control behaviour between its three phases.Source: C. Multistage Task Execution · p. 5
• The cited passage identifies surface wiping as requiring the robot to maintain something steady, but the excerpt does not specify what must remain steady.Source: C. Multistage Task Execution · p. 5
• For tool release and return, the robot moved the sponge to its designated spot and returned to its start using stiff joint impedance at K = 800 N/m.Source: C. Multistage Task Execution · p. 5
• The multimode controller was benchmarked against the ros2_control baseline over 10 runs per approach using completion time and peak trajectory jerk.The supplied passages specify the evaluation design but do not report the benchmark results.Source: C. Multistage Task Execution · p. 5

A. Control Behaviour Switching Delay

• 0.01 ms average switching delay for the improved multimode controller compares with 1.8 ms for the default multimode controller and approximately 210 milliseconds for ros2 control.The worst observed switch for the proposed approach remained below 0.1 ms across 100 trials.Source: Figure 4 · p. 5, A. Control Behaviour Switching Delay · p. 5

B. Reflex Behaviours

• Joint 2 produced the highest stopping distances and, carrying most of the robot weight in the default mounting, created the most demanding stopping conditions.Even the highest observed values did not reach the hardware limit, which would completely stop the robot and produce high jerks.Source: B. Reflex Behaviours · pp. 5–6, Figure 6 · p. 6
• 0.082 ± 0.003 rad for position-limit tests and 0.080 ± 0.016 rad for velocity-limit tests were the mean stopping distances averaged across all 7 joints.The means were comparable, while stopping-distance variability was significantly higher during velocity-limit tests because joint velocities were higher when the reflex triggered.Source: B. Reflex Behaviours · p. 5, Figure 5 · p. 6
• Fig. 6 displays joint 2 position and velocity trajectories for the position- and velocity-limit tests.Joint 2 produced the highest stopping distances; recorded joint angles and velocities are shown against their respective colour-coded vertical axes.Source: B. Reflex Behaviours · p. 5, Figure 6 · p. 6
• 0.122 ± 0.013 s was the mean force mitigation time across 30 contact-detection trials for external forces exceeding 15 N.Low-level hardware limits were not triggered, allowing uninterrupted execution throughout the experimental procedure.Source: B. Reflex Behaviours · p. 6, Figure 7 · p. 6
• Fig. 8 illustrates end-effector stopping behaviours using measured external-force and velocity magnitudes.The trajectories correspond to the respective colour-coded vertical axes.Source: Figure 8 · p. 6, B. Reflex Behaviours · p. 6

C. Multistage Task Execution

• Nearly 0.5 s faster task completion was reported, with the enhanced multimode controller compared against the ros2 control baseline across 20 trials.The task evolution is shown in Fig. 9; Tab. II reports the quantitative comparison scope (N = 10 per configuration).Source: C. Multistage Task Execution · p. 6, Table II · p. 6, Figure 9 · p. 6
• Peak operational-space jerk fell from 499.0 ± 96.9 m/s3 to 155.4 ± 40.6 m/s3 with smoother multimode-controller switches.Source: C. Multistage Task Execution · p. 6

A. Control Behaviour Switching Delay

• Switching delay was reduced by more than 4 orders of magnitude versus standard open-source ros2 control, reaching below 0.1 ms.Source: A. Control Behaviour Switching Delay · pp. 6–7
• The approach is compatible with existing ros2 control systems by adding a copied controllet, and its sub-0.1 ms latency lets reflexes run within the 1 kHz control loop.Source: A. Control Behaviour Switching Delay · p. 7

B. Reflex Behaviours

• Limit-test reflexes succeeded, but stop reflexes using soft joint impedance overshot the specified limits, making threshold and reflex selection application-dependent.The tests used δq = 0.2 rad and δ ˙q = 0.1 rad/s; the stop reflex used spring behaviour with K1−4 = 200 N/m and K5−7 = 100 N/m.Source: B. Reflex Behaviours · p. 7
• Collision tests detected peak transient forces above the set threshold, but sub-millisecond state transitions engaged reflexes during Impact Phase II and removed static crushing forces before manufacturer limiters tripped.The initial open-loop Impact Phase I force peak cannot be attenuated by active feedback; the reflex prevented sensor saturation and rigid emergency stops.Source: B. Reflex Behaviours · p. 7
• Supplementary videos show reactions to unexpected contact that transition to suitable reflexes and resume operation after hazards resolve without low-level safety stops.These examples extend beyond the controlled, repeatable evaluation scenarios.Source: B. Reflex Behaviours · p. 7

C. Multistage Task Execution

• Approx. 0.5 s of delay in the baseline task came from fully stopping before each new behaviour, while the proposed approach's task-space velocity never reached zero at the direction change.The example is a simplified representative real-world scenario with two control behaviour switches.Source: C. Multistage Task Execution · p. 7
• More than a threefold reduction in observed jerk may reduce mechanical loads during controller transitions.The paper advises considering observed jerk before deployment.Source: C. Multistage Task Execution · p. 7

VII. CONCLUSION

• The open-source switching methodology was experimentally validated on a Franka Robotics manipulator and combines ROS 2 compatibility and modularity with timing constraints and determinism.It avoids requiring a single unified control strategy.Source: §VII · p. 7
• Switching delays of < 0.1 ms and five implemented reflex behaviours enable continuous operation while mitigating critical external forces and intercepting joint position and velocity limits before manufacturer safety stops.The transitions fall within latency ranges consistent with controller frequencies commonly required by collaborative robotics safety standards.Source: §VII · p. 7
• Task duration fell by 3.5% and maximum detected trajectory jerk by more than threefold versus standard ros2 control in the multistage task, which required only two switches.The paper states that smoother transitions may benefit long-term continuous operation and motion smoothness.Source: §VII · p. 7
• Experiments were limited to predefined reflex behaviours and application-dependent safety thresholds; future work will extend the library and refine controller-specific parameters, especially for task-preserving hazard mitigation.The paper also proposes learned robot policies as a potential application for rapid transitions to established control strategies.Source: §VII · p. 7
• The stated goal is to let robots react, recover, and continue operating during physical interaction, providing an accessible, modular foundation for continuously operating service robots.The framework is presented as bringing reflex-level responsiveness to open-source robotic middleware.Source: §VII · p. 7