Robot Control Stack (RCS)

• Robot Control Stack (RCS) is a layered architecture that explicitly segments perception, planning, control, and hardware execution to enable robust robotic systems.
• It integrates diverse modules—from sensory input and hierarchical planning to real-time control and specialized solvers—applicable in manipulation, navigation, and surgical platforms.
• RCS designs employ unified simulation-to-real pipelines, risk-aware planning, and language-assisted orchestration to ensure modular, adaptable, and safe robot operation.

Robot Control Stack (RCS) denotes, in the cited literature, an end-to-end control architecture that connects perception, planning, task logic, low-level control, and hardware execution. The term is used both for general layered blueprints and for named implementations: prioritized Stack-of-Tasks combined with Behavior Trees, ROS2-native torque controllers for learning-based manipulation, wrapper-based ecosystems for simulation and physical robots, multi-robot navigation stacks, and surgical teleoperation and autonomy platforms (Domínguez et al., 2022, Pro et al., 8 Sep 2025, Jülg et al., 18 Sep 2025, Şenbaşlar et al., 2023, Rodriguez et al., 9 Mar 2026). Across these systems, RCS is characterized by explicit layer boundaries, unified interfaces, runtime safety checks, and mechanisms for synchronous or asynchronous execution.

1. Architectural scope and recurring structure

In the literature, RCS is not a single software package or a single control law. It appears as a layered architecture whose boundaries depend on the application domain. R4 defines the stack as the end-to-end pathway from high-level planning and ROS2 middleware down to low-level actuation and sensing (Waltham et al., 2024). RPC organizes a framework into simulators, an Interface layer, a Planning and Control layer, and a Visualization / User Interface layer (Bang et al., 2024). The lean RCS ecosystem for robot learning is organized around a hardware/device layer, a control/trajectory layer, a skill/policy layer implemented as environment wrappers, and task/experiment orchestration through a Gymnasium API (Jülg et al., 18 Sep 2025). SpaceDREAM places a mission executive, state machines, real-time control, device interfaces, telemetry, and fault recovery on an on-board computer (Mühlbauer et al., 2024). Franka-Interface and FrankaPy split the stack into a high-level Python client and a low-level C++ real-time server (Zhang et al., 2020).

Stack	Primary emphasis	Representative feature
SoT + BT (Domínguez et al., 2022)	Reactive manipulation	BT at high level, SoT at control level
CRISP (Pro et al., 8 Sep 2025)	Torque-level compliance	1 kHz compliant Cartesian and joint-space control
RCS ecosystem (Jülg et al., 18 Sep 2025)	Robot learning at scale	Unified sim-real wrapper architecture
MRNAV (Şenbaşlar et al., 2023)	Multi-robot navigation	Long-, medium-, and short-horizon modules
Surgical platform (Rodriguez et al., 9 Mar 2026)	Minimally invasive robotics	Closed-form RCM velocity controller

The architectural pattern is therefore broad enough to include research manipulation stacks, multi-robot navigation systems, space-qualified mission software, and learning-oriented deployment pipelines. This suggests that RCS is best understood as an organizing principle: a structured composition of interfaces, estimators, planners, controllers, safety mechanisms, and hardware drivers, rather than a fixed implementation.

2. Interfaces, middleware, and execution semantics

A central property of RCS implementations is the way they separate timing domains. In the SoT+BT framework, the Behavior Tree ticks at a relatively low and variable frequency of 2–110 Hz, while the Stack-of-Tasks controller runs at 220–1500 Hz and solves hierarchical QPs in joint velocity space (Domínguez et al., 2022). CRISP uses high-level policy or teleoperation nodes that publish target commands at 5–30 Hz, whereas the torque controller runs at 1 kHz on a real-time Linux workstation (Pro et al., 8 Sep 2025). Franka-Interface similarly places low-level control at 1 kHz under libfranka, with high-level Python commands transmitted through ROS Actions and Protocol Buffers (Zhang et al., 2020). SpaceDREAM runs a 100 Hz real-time controller, with parabolic flight tests reporting sustained 100 Hz and approximately 0.5 ms average jitter (Mühlbauer et al., 2024).

The communication substrate varies across stacks. ROS and ROS2 are common, but they are not universal. Control Your Robot explicitly supports ROS1/ROS2-based communication and exposes unified APIs for registered controllers and sensors (Nian et al., 28 Sep 2025). CRISP is implemented as a ros2_control controller plugin managed by controller_manager (Pro et al., 8 Sep 2025). Franka-Interface uses ROS on the client–server path but shared memory between the ROS Action Server and the real-time loop to avoid serialization in the 1 kHz path (Zhang et al., 2020). SpaceDREAM uses the “links and nodes” middleware, with topic-based cyclic communication, services, parameters, and a Python process manager (Mühlbauer et al., 2024). R4 uses ROS2 nodes over WiFi UDP ASCII datagrams, with default 100 Hz state datagrams, 2 Hz heartbeats, and a 1 s heartbeat timeout (Waltham et al., 2024).

Execution semantics differ accordingly. The learning-oriented RCS ecosystem makes synchronous step semantics the default: environment step blocks until the defined target state has been reached, and all sensors returned at step $t+1$ are time-aligned (Jülg et al., 18 Sep 2025). The same stack also supports asynchronous mode, useful for teleoperation or streaming control. This distinction matters because some research stacks are optimized for deterministic learning pipelines, whereas others are optimized for reactive teleoperation or continual control.

3. Control-theoretic core

The control layer is the defining technical core of an RCS. In the SoT formulation, each task is defined by an error function $e(q)$ and Jacobian $J(q)$, with first-order task dynamics

$$\dot{e}(q) = J(q)\dot{q}, \qquad \dot{e}^*(q) = -K_p e(q),$$

and equality or inequality tasks enforced through hierarchical QPs with slack variables frozen across priorities (Domínguez et al., 2022). This realizes strict lexicographic task priority without explicit null-space projection. In collaborative fine manipulation, the intuitive Stack-of-Tasks formulation extends the same task-priority idea with Cartesian pose tasks, force-based tasks, manipulability objectives, and joint-limit avoidance, again solved through recursive constrained QPs (Katyara et al., 2021).

A second major line is torque-level compliant control. CRISP implements Cartesian Impedance and Operational Space Control, optional nullspace joint impedance, gravity/Coriolis/friction compensation, joint limit barriers, and wrench control, with the final torque

$$\tau_{cmd} = \tau_{task} + \tau_{ns} + \tau_{joint\_barrier} + \tau_{gravity} + \tau_{coriolis} + \tau_{friction} + \tau_{wrench}.$$

It exposes both static and dynamic nullspace projectors and uses pinocchio-based kinematics and dynamics (Pro et al., 8 Sep 2025). SpaceDREAM likewise relies on joint-level position and impedance modes, Cartesian impedance via Virtual Fixtures, and computed-torque forms when needed (Mühlbauer et al., 2024). RPC generalizes this to whole-body settings with IHWBC and WBIC, working over Task/Contact/InternalConstraint abstractions and Pinocchio-based dynamics (Bang et al., 2024).

Other stacks embed problem-specific control laws. The surgical platform uses a closed-form analytical Remote Center of Motion velocity solver. With shaft direction $\mathbf{u}$, end-effector-to-trocar vector $\mathbf{r}_{ee}$, tip velocity $\mathbf{v}_{tip}$, and roll rate $\omega_{roll}$, it computes

$$\boldsymbol{\omega}_{pivot} = \frac{\mathbf{r}_{shaft} \times \mathbf{v}_{tip}}{\lVert \mathbf{r}_{shaft} \rVert^2}, \qquad \mathbf{v} = s\mathbf{u} - \boldsymbol{\omega}\times \mathbf{r}_{ee},$$

thereby enforcing the trocar constraint deterministically without iterative optimization (Rodriguez et al., 9 Mar 2026). In uncertainty-aware planning and control, the risk-bounded stack combines a decorrelation-scheme UKF with nonlinear MPC and distributionally robust chance constraints, so that perception and prediction uncertainty explicitly tighten motion constraints rather than remaining outside the planner (Renganathan et al., 2022). These formulations show that “control” in RCS ranges from prioritized kinematic optimization, to operational-space torque control, to robust MPC, to application-specific analytic solvers.

4. Perception, estimation, and state representation

Perception in an RCS is not merely upstream sensing; it defines the state variables over which control and planning are posed. The SoT+BT manipulation framework uses object pose from Kinect V2 and fiducial markers, together with mission progress and condition nodes in the tree (Domínguez et al., 2022). The collaborative visuo-tactile system combines two depth cameras and tactile sensors: one depth camera estimates human-arm posture at 5 Hz, an eye-in-hand depth camera performs point-cloud segmentation and SVM-based object classification at 25 Hz, and tactile sensing estimates contact deformation and force at much higher rates (Katyara et al., 2021). In ARRC, AprilTag detections are fused with depth from an Intel RealSense D435 to produce object-centric metric poses in the base frame, with a lightweight temporal filter to smooth jitter (Vorobiov et al., 7 Oct 2025).

State estimation can be much more structured. The risk-bounded planning stack represents robot and environment together in an integrated environmental state $e(q)$0, estimated by a decorrelation-scheme Unscented Kalman Filter. That estimator propagates both robot-state covariance and environment-state covariance and feeds them into distributionally robust motion constraints (Renganathan et al., 2022). LF uses a Kalman filter at controller rate to estimate 6-DoF pose and first and second derivatives from motion-capture measurements (Shankar et al., 15 Jul 2025). MRTA-Sim assumes robot states, human states and velocities, ray-traced nearest obstacle points, and local sharing of neighbor states for local centralized deconfliction (Tuck et al., 21 Apr 2025). The surgical platform derives the stereo camera frame from forward kinematics and a measured tool offset, while synchronizing multiple machines through Precision Time Protocol (Rodriguez et al., 9 Mar 2026).

A recurring pattern is that the state representation is tightly coupled to the intended controller. Visuo-tactile deformation estimates are meaningful because the controller enforces friction-cone-related contact stability (Katyara et al., 2021). Integrated environment covariance is meaningful because the planner enforces risk bounds (Renganathan et al., 2022). Stereo kinematics and trocar geometry are meaningful because the controller operates on the RCM manifold (Rodriguez et al., 9 Mar 2026). This suggests that an RCS does not simply consume sensor streams; it codifies state variables that are immediately actionable by downstream modules.

5. Planning, task composition, and policy deployment

The planning and orchestration layer is where different RCS traditions diverge most strongly. In reactive manipulation, Behavior Trees are used to compose single SoT tasks, gate them by conditions, and encode blocking or non-blocking semantics. Their two-way control transfer—ticks downward, statuses upward—supports reactivity, modularity, and reusability in ways contrasted with FSM “Goto-style” one-way transitions (Domínguez et al., 2022). Franka-Interface packages high-level behavior as “skills,” each formed by combining a trajectory generator, a feedback controller, and a termination handler (Zhang et al., 2020).

In learning-oriented stacks, planning is often replaced or complemented by wrappers, data pipelines, and deployment interfaces. The wrapper formalism in the lean RCS ecosystem defines an environment wrapper as

$e(q)$1

with action propagation

$e(q)$2

and observation propagation

$e(q)$3

This makes simulation and hardware share the same application and rollout interface (Jülg et al., 18 Sep 2025). Control Your Robot follows a related logic with robot registration, dual-mode teleoperation and trajectory playback, synchronized 30 Hz data capture, automated fine-tuning, and a unified inference API (Nian et al., 28 Sep 2025). CRISP extends this pattern downward by providing ROS2-native compliant tracking for low-frequency learned policies and teleoperation (Pro et al., 8 Sep 2025).

Multi-robot RCS designs make the planning hierarchy explicit. MRNAV separates long-horizon global route guidance, medium-horizon decentralized receding-horizon planning, and short-horizon action-level safety, and argues that all three are required for effective navigation in cluttered environments (Şenbaşlar et al., 2023). LF uses a centralized MAPF planner at 5–10 Hz and per-robot optimal trajectory controllers at 50–100 Hz, explicitly shifting from a coupled discrete planning representation to a decoupled continuous tracking representation (Shankar et al., 15 Jul 2025). MRTA-Sim connects allocation output to NAV2 global planning and local CBF-QP deconfliction, thereby testing allocation methods with navigation and control layers “in the loop” rather than assuming approximate travel times (Tuck et al., 21 Apr 2025).

A newer direction embeds LLMs inside the orchestration layer. LA-RCS uses a dual-agent framework in which a Host Agent constructs a Global Plan from the user request, observations, sensor data, and memory, while an App Agent iteratively chooses concrete control functions and returns CONTINUE or FINISH (Park et al., 23 May 2025). ARRC uses retrieval-augmented generation to retrieve movement primitives, templates, and safety heuristics, condition a LLM, and produce JSON-structured plans that are then validated and executed under software safety gates (Vorobiov et al., 7 Oct 2025). These stacks do not remove the need for low-level control; they relocate planning into a semantic layer while retaining local execution and safety.

6. Safety, robustness, evaluation, and applications

Safety mechanisms in RCS implementations are heterogeneous but systematic. CRISP enforces joint limit barriers, torque and torque-rate limits, error clipping, target filtering, and nullspace stabilization, while noting that collision detection must come from external modules (Pro et al., 8 Sep 2025). ARRC uses workspace bounds, speed and force caps, timeouts, bounded retries, and emergency opening of the gripper under overload (Vorobiov et al., 7 Oct 2025). R4 combines heartbeats, dead-man’s-handle circuitry, proximity-triggered interlocks, automotive fuses, and a safe-state on heartbeat loss or WiFi disconnect (Waltham et al., 2024). SpaceDREAM layers a mission executive, hardware watchdogs, systemd supervision, randomized eMMC selection, subsystem disablement, and reboot/hard-reset procedures for radiation-tolerant autonomy (Mühlbauer et al., 2024). The lean RCS ecosystem uses digital twins to execute actions in simulation first and block unsafe commands before they reach hardware (Jülg et al., 18 Sep 2025).

Robustness is usually evaluated quantitatively. In the SoT+BT manipulation experiments on a Franka Emika Panda, 50 trials over five initial cube poses yielded 90% first-attempt success, 100% success on retried second attempts, and 94% overall success; local disturbance handling by SoT succeeded in 92% of trials and global disturbance handling by BT in 88% (Domínguez et al., 2022). CRISP reported steady-state position errors of 5.54 mm for OSC, 4.73 mm for CI, and 0.81 mm for CI with error clipping on a discontinuous pose tracking task, with corresponding steady-state rotation errors of 0.0998 rad, 0.0532 rad, and 0.0029 rad (Pro et al., 8 Sep 2025). The surgical platform reported sub-millimeter RCM deviations, with figure medians of 0.035 mm in phantom, 0.052 mm ex vivo, and 0.079 mm in vivo, and an imitation-learned bowel grasping and retraction policy that achieved 85% success, or 17/20 roll-outs (Rodriguez et al., 9 Mar 2026).

Large-scale and long-duration evaluations show another facet of RCS design. The lean RCS ecosystem reported data collection at 30 Hz, RL throughput exceeding 2000 environment steps per second with 24 parallel environments, and a vanilla PPO policy reaching 100% success in approximately 3 hours, or 8.5M steps, on a Pick-Cuboid task in simulation (Jülg et al., 18 Sep 2025). MRNAV demonstrated an eight hour long wall time, six hour long simulation time, uninterrupted run with zero collisions and deadlocks (Şenbaşlar et al., 2023). LF reported solutions under 200 ms for moderate teams of roughly 32 robots, around 250 ms for 100 robots with smaller radii, and a video demonstration at about 500 robots solved in approximately 3.5 s (Shankar et al., 15 Jul 2025). LA-RCS evaluated 20 user requests across four scenario types and reported 18/20 success, or 90%, for GPT-4o (Park et al., 23 May 2025). ARRC reported 8/10 plan validity, 10/10 scan detection, mean approach accuracy of 87.1%, and 8/10 pick-place success (Vorobiov et al., 7 Oct 2025).

The application range is correspondingly broad: fine manipulation with visuo-tactile coordination (Katyara et al., 2021), compliant learning-based manipulation and teleoperation (Pro et al., 8 Sep 2025), simulation-to-hardware robot learning (Jülg et al., 18 Sep 2025), whole-body locomotion and manipulation (Bang et al., 2024), multi-robot navigation (Şenbaşlar et al., 2023), in-space servicing and assembly (Mühlbauer et al., 2024), and autonomous laparoscopic surgery (Rodriguez et al., 9 Mar 2026). A plausible implication is that the modern RCS is no longer reducible to “planner plus controller.” It is a layered systems construct in which control laws, perception models, synchronization mechanisms, middleware choices, data logging, and safety monitors are treated as first-class research objects.