Robot Maneuver Coordination Service

• Robot Maneuver Coordination Service (RMCS) is a robot-centric coordination mechanism that enables the exchange of explicit maneuver intent and negotiation messages between heterogeneous agents.
• RMCS architectures span facility-layer V2X implementations, ROS interfaces, and aggregate-programming runtimes to support leader-follower and multi-robot choreographies.
• Empirical evaluations show RMCS can improve coordination success rates, reduce negotiation latency, and enhance overall safety in dynamic, decentralized settings.

Searching arXiv for the cited RMCS-related papers to ground the article in published work. Robot Maneuver Coordination Service (RMCS) denotes, in the recent literature, a robot-centric coordination service for exchanging maneuver intent, negotiation messages, and execution feedback so that heterogeneous robots can perform collaborative maneuvers under explicit roles, local communication constraints, and, in several formulations, V2X facility-layer semantics. In the V2X setting, RMCS is introduced as a facility-layer service realized through the Robot Maneuver Coordination Message (RMCM) and activated after the Robot Awareness Service (RAS) has established roles; in broader multi-robot systems work, the same label is used for coordination middleware spanning aggregate-programming runtimes, ROS service interfaces, and mission-specific executors such as CoBot–ARDrone search coordination (Arockiasamy et al., 7 May 2026, Audrito et al., 8 Apr 2026, Konam et al., 2017). A recurring result across these formulations is that direct intent-sharing materially improves coordination effectiveness relative to ego-side trajectory extrapolation, which is why several RMCS blueprints treat maneuver intent as a first-class protocol primitive (Molina-Masegosa et al., 23 Jun 2026).

1. Definition, operating context, and service boundary

RMCS is defined most explicitly in the ETSI ITS-G5 V2X architecture as the facility-layer service whose sole purpose is to let heterogeneous robots coordinate safety-critical maneuvers in a fully decentralized, event-driven fashion. In that formulation, RMCS activates once two or more robots agree on a collaborative task via RAS, and its role is to carry bidirectional, low-latency maneuver commands and execution responses, thereby enabling leader-follower choreography such as blocking vehicular traffic, guiding a pedestrian, and forming safety corridors without any centralized infrastructure or prior pairing (Arockiasamy et al., 7 May 2026).

A central boundary in the literature separates awareness from coordination. RAS, realized by Robot Awareness Messages (RAMs), establishes robot roles, task progression, and VRU clustering; RMCS, realized by RMCMs, carries the maneuver requests, acknowledgments, and execution feedback that act on those roles. This distinction matters because periodic awareness dissemination and event-driven maneuver negotiation solve different problems: awareness supports mutual situational knowledge, whereas RMCS supports explicit agreement on who will do what, when, and under which constraints (Arockiasamy et al., 7 May 2026).

Outside V2X road-crossing scenarios, RMCS appears as a broader coordination abstraction for multi-robot systems operating over peer-to-peer UDP broadcast, mesh WiFi, ROS topics and services, or ad-hoc networks. In these variants, the service may support task assignment, rendezvous, formation maneuvers, aisle-change analogues of lane changes, or indoor launch-search-recovery workflows between a ground robot and a UAV (Audrito et al., 8 Apr 2026, Konam et al., 2017, Tian et al., 11 Aug 2025). Federated fleet architectures extend the same idea further: each robot remains a single embodied runtime with its own policy scope and recovery authority, while coordination emerges through federation across robots at the fleet level rather than through intra-robot multi-agent fragmentation (Qin et al., 13 Apr 2026).

2. Protocol structures and message semantics

Across the literature, RMCS protocols are built around explicit maneuver semantics rather than raw state broadcast. One intent-sharing blueprint uses Maneuver Coordination Messages denoted MCM or MSCM per SAE J3186 or ETSI MCM TS 103 561, with planned trajectories represented as sequences of future waypoints

$\{(t_k,x_k,y_k,v_k)\mid k=0\ldots K\},$

where $t_0=\text{timestamp}$ and $t_K\approx 5\,\text{s}$ in the future. The same blueprint specifies desired maneuver parameters such as target lane, desired speed profile, and lateral acceleration limits, together with timing profiles $(t_{\text{start}}, t_{\text{end}})$ and vehicle identification and state (Molina-Masegosa et al., 23 Jun 2026). In the ETSI robot-centric RMCS, the RMCM PDU is composed of an ItsPduHeader and GenerationDeltaTime plus optional LeaderManeuverContainer and FollowerManeuverContainer fields, including requestID, targetFollowerStationID, taskType, maneuverParameters, jobAdviceID, and executionStatus (Arockiasamy et al., 7 May 2026). Other RMCS formulations use seven-message or three-message families for maneuver negotiation, but the common pattern is still request, response, acknowledgment, execution, and completion/failure exchange (Mizutani et al., 2021, Monteuuis et al., 2022).

Protocol lineage	Principal messages or containers	Characteristic payload elements
Intent-sharing MCM/MSCM	Request, Response, Confirmation, Intent	msgType, seqNum, trajectoryPointCount, $\Delta t_k,\Delta x_k,\Delta y_k,v_k$
ETSI robot-centric RMCM	LeaderManeuverContainer, FollowerManeuverContainer	requestID, targetFollowerStationID, taskType, waypoints, executionStatus
AutoMCM-style RMCS	Advertisement, Intention, Prescription, Acceptance, Fin, Cancel, Ack	coord_id, planned or prescribed trajectory, accept
MCR-style RMCS security model	MCR-Req, MCR-Resp, MCR-Update	Session ID, participant list, TRR, start/end time, kinematic constraints

The RMCM workflow in the V2X formulation is leader-centric and event-driven. The leader broadcasts an RMCM with a LeaderManeuverContainer to all robots in its RAS-established group; each targeted follower immediately replies with an RMCM containing a FollowerManeuverContainer with executionStatus=acknowledged; the follower then executes the commanded maneuver and sends another RMCM with executionStatus={completed, failed}; throughout the exchange, both parties continue to exchange RAMs so that other road users maintain awareness of their evolving roles, positions, and VRU clustering (Arockiasamy et al., 7 May 2026).

Intent-sharing blueprints expose similar semantics through application APIs such as sendIntent(Trajectory traj), onReceiveIntent(VehicleID id, Trajectory traj), sendRequest(ManeuverSpec spec), onReceiveResponse(...), and sendConfirmation(...), while AutoMCM-style services present asynchronous JSON-RPC over WebSocket methods such as initializeManeuver, publishPlannedTrajectory, sendPrescription, sendAcceptance, terminateManeuver, and queryState (Molina-Masegosa et al., 23 Jun 2026, Mizutani et al., 2021). The coexistence of RMCM, MCM/MSCM, AutoMCM, and MCR-style message sets suggests that RMCS is presently better understood as a design space than as a single frozen wire protocol.

3. Coordination formalisms and algorithmic models

A formally specified finite-state coordination model appears in the V2X road-crossing realization of RMCS. There the coordination state set is

$$S=\{\text{Idle},\text{HelpRequested},\text{RoleEstablished},\text{ManeuverExecuting}\},$$

the event set is

$$E=\{\text{PedestrianDetected},\text{HelpOffered},\text{RoleConfirmed},\text{ManeuverInstruction},\text{ManeuverCompleted},\text{TaskCompleted}\},$$

and the transition function $\delta:S\times E\to S$ includes

$$\delta(\text{Idle},\text{PedestrianDetected})=\text{HelpRequested},$$

$$\delta(\text{HelpRequested},\text{HelpOffered})=\text{RoleEstablished},$$

$t_0=\text{timestamp}$0

$t_0=\text{timestamp}$1

$t_0=\text{timestamp}$2

This model makes the handoff from role establishment to maneuver execution explicit and is paired with event-triggered RMCM exchange (Arockiasamy et al., 7 May 2026).

A second line of work implements RMCS through Aggregate Programming (AP). In that setting, the coordination layer is an Exchange Calculus runtime with self-stabilizing operators G, C, and T, together with aggregate processes such as spawn, align, and exchange. The key AP primitives are rep(initial){ (old) ⇒ f(old) }, nbr{ e }, and foldhood(z)(⊕){ nbr{e} }; the core formulas include the hop-count gradient

$t_0=\text{timestamp}$3

state evolution

$t_0=\text{timestamp}$4

and neighborhood aggregation

$t_0=\text{timestamp}$5

Path planning, obstacle avoidance, rendezvous, and leader-election-based task assignment are all expressed in this style (Audrito et al., 8 Apr 2026).

A third formulation pushes RMCS into formally verified distributed motion coordination under LTL specifications. Each robot runs three layers: offline pre-computation, initialization, and online coordination. The online layer performs conflict detection on reserved grid cells and time intervals, assigns dynamic planning order among neighboring robots, and generates local collision-free trajectories through an RRT-style search. The mode logic is Free, Busy, and Emerg; if planning fails, the robot applies the braking controller until stop and continues conflict detection and replanning attempts. Safety is guaranteed when the sensing radius satisfies

$t_0=\text{timestamp}$6

under the stated assumptions (Yu et al., 2021). This suggests that RMCS can be instantiated both as a negotiation service over explicit maneuver messages and as a motion-coordination substrate with formal safety and correctness guarantees.

4. Architectural patterns and implementation styles

Several RMCS implementations adopt layered software architectures. An intent-sharing blueprint proposes the modules Sensor & V2X Input, Trajectory Manager, Prediction Engine, Coordination Trigger, Negotiation Manager, Execution Controller, and Fault Handler, with a data flow [Sensors/CAM] → Trajectory Manager → Prediction Engine → Coordination Trigger → Negotiation Manager ↔ Remote RMCS Agent → Execution Controller → Vehicle Motion Module. The same blueprint specifies a binary TLV message schema Type(1B)|Len(2B)|Seq(2B)|VehicleID(4B)|Timestamp(8B)|Payload… (Molina-Masegosa et al., 23 Jun 2026).

The AP-based service prototype adopts a layered stack consisting of Device Capabilities, Communication Substrate, Coordination Layer (Aggregate Programming Runtime), Service [API](https://www.emergentmind.com/topics/adversarial-prompt-injection-api) Layer (RMCS), and Application Layer. Its external service interface exposes REST or ROS2-service-style endpoints including /register_robot, /update_status, /submit_task, /query_assignment, and /heartbeat, while the AP runtime handles consensus and assignment internally (Audrito et al., 8 Apr 2026).

Human-in-the-loop exploration systems extend RMCS to operator stations. In MoRoCo-inspired designs, each robot and operator station runs logically identical layers: SLAM Manager, Communication Manager, Coordination Manager, and Failure Recovery, with operators additionally hosting a Human-Interface Module based on an Rviz GUI. Coordination is organized around three modes, Spread, Migrate, and Chain, and packets are routed only at planned communication events over a local ad-hoc network with no fixed infrastructure (Tian et al., 11 Aug 2025).

Federated runtime architectures reinterpret RMCS as contract-aware cross-robot coordination. In FSAR, each robot runtime is

$t_0=\text{timestamp}$7

where $t_0=\text{timestamp}$8 is agent identity, $t_0=\text{timestamp}$9 the installed Embodied Capability Modules, $t_K\approx 5\,\text{s}$0 the local policy scope, $t_K\approx 5\,\text{s}$1 the trust state, $t_K\approx 5\,\text{s}$2 the local recovery authority and budgets, and $t_K\approx 5\,\text{s}$3 the human-in-the-loop interface. Fleet coordination is then defined over

$t_K\approx 5\,\text{s}$4

with shared capability registry, delegation engine, policy composer, recovery orchestrator, and hierarchical human supervision (Qin et al., 13 Apr 2026).

At the opposite end of the architectural spectrum, RMCS can be mission-specific and lightweight. In the CoBot–ARDrone system, the coordination middleware is a ROS-based framework in which CoBot offers a Launch-Drone service, the UAV-side Maneuver Coordination Service node subscribes to video and publishes velocity commands, and state-monitoring topics such as /cobot/mission_state and /drone/vision_state encode the mission FSM. The ground robot provides global navigation and localization, while the UAV executes local search and recovery by video-based moving-target visual servo (Konam et al., 2017).

5. Evaluation methodologies and reported performance

A common RMCS metric is coordination success probability. One intent-sharing blueprint defines a coordination attempt as successful or unsuccessful and uses

$t_K\approx 5\,\text{s}$5

with confidence intervals via Wilson score and a binomial model for success counts. In the highway scenario without obstacle, at density $t_K\approx 5\,\text{s}$6 the baseline achieved 4.1 success, 3.1 failure → P_success=57.3%, whereas intent-sharing achieved 4.4 success, 0.7 failure → P_success=85.2%; at density $t_K\approx 5\,\text{s}$7 the baseline achieved 5.1 success, 5.2 failure → P_success=41.0%, whereas intent-sharing achieved 6.2 success, 1.6 failure → P_success=79.1%. In the obstacle scenario, the results were 4.4/3.6 (55.3%) versus 5.3/1.0 (84.6%) at density 15, and 4.5/5.0 (47.3%) versus 6.0/1.6 (78.9%) at density 25. The reported benefit is a reduction in failure rate by ~65–75%, an increase of successful events by 20–38%, highest gain at high density, and diminishing returns beyond dpred≈500 m (Molina-Masegosa et al., 23 Jun 2026).

Real-world V2X evaluation of RMCS reports deterministic multi-robot coordination between an ARI humanoid and a RoboDog quadruped assisting a pedestrian during a road-crossing scenario. Negotiation latency $t_K\approx 5\,\text{s}$8 was measured at 0.074 ± 0.015 s for the initialPos maneuver and 0.129 ± 0.102 s for pedestrian escort; execution latency $t_K\approx 5\,\text{s}$9$(t_{\text{start}}, t_{\text{end}})$0$ was 0.574 ± 0.015 s and 21.729 ± 0.102 s respectively. The same work reports that explicit RMCM acknowledgments and periodic RAM ensure > 99 % reliability and deterministic recovery from message loss. In mixed-traffic simulations, robots acting as mobile cluster heads achieved up to 18 % observation coverage (OBS) of pedestrian travel time with nine robots at 15 m sensing radius, while robot-mediated clustering reduced mean Channel Busy Ratio (mCBR) by up to 16.3 % in a 100 pedestrians, nine robots, 15 m radius configuration (Arockiasamy et al., 7 May 2026).

AP-based RMCS evaluation reports ∼5 ms round-trip latency per exchange, one broadcast per 200 ms cycle with 32 bytes payload, ~10 rounds convergence for hop-gradient in a 5 m diameter arena, and ~15 rounds for leader election. In Gazebo simulation, throughput reached 20 tasks/minute sustained; after robot failure, re-assignment occurred within 3–5 rounds (0.6–1 s); in physical tests with 2–5 iRobot Create3 robots, average navigation plus coordination end-to-end for a shelf pickup was 12.5 s; and the system exhibited graceful degradation up to 30% robot loss without system-wide stall (Audrito et al., 8 Apr 2026).

AutoMCM-style evaluation emphasizes communication efficiency and traffic-flow benefit. Event-driven exchange reduces maneuver-coordination frames to ~5–10 per maneuver rather than 10 Hz continuous, yielding ≈10× bandwidth savings; in a 260 m lane-change scenario, arrival time was reduced by 5 s (15 %) at 30 km/h and by 7 s (28 %) at 50 km/h (Mizutani et al., 2021). Human-in-the-loop exploration reports 100% coverage with 585 s completion time and 118 s maximum latency for the full MoRoCo method in a Building 60×50 m, 1 op+4 ro setup, as well as a hardware trial producing a 1072 m² final map in 2500 s, maximum intra-team latency ≈260 s < T_h=300 s, inter-team chain at t=1565 s < T_c=1800 s, and two high-bandwidth tasks via Chain mode in ~30 s transition (Tian et al., 11 Aug 2025). In the CoBot–ARDrone prototype, all experiments were repeated 20×; timing was measured on the ground-station clock with ms resolution; reported means were 0.7 ms for navigation-to-marker, 9.40 ms for forward search plus hover, and 16.25 ms for forward search plus return plus landing, with a hover localization-error threshold of 50 px (Konam et al., 2017). This suggests the reported evaluations are scenario-specific rather than directly comparable as a single benchmark.

6. Reliability, security, and open research directions

RMCS reliability requirements are stringent because maneuver coordination is latency-sensitive and safety-critical. One intent-sharing design specifies end-to-end latency < 100 ms for coordination messages, with < 50 ms preferred; intent sharing at at least 1 Hz or whenever the trajectory changes by more than Δpos=0.5 m/Δvel=0.5 m/s; negotiation messages at 10 Hz (every 100 ms); packet delivery ratio ≥ 99.5% for Request/Response and ≥ 98% for Intent; link-layer ARQ per IEEE 802.11p; application-layer retransmission if no response arrives in 1 s; negotiation timeout = 1 s; and execution timeout = t_estimatedCompletion + 3 s margin. The same blueprint prescribes fallback to baseline prediction upon sustained communication failures \>200 ms, marks neighbor predictions as stale if no intent update is received in \>1.5 s, retries requests up to 10 times, and aborts if actual lane-change deviates by \>1 s from the plan (Molina-Masegosa et al., 23 Jun 2026).

Security analyses show that these transport and timeout mechanisms are not sufficient by themselves. RMCS inherits the attack surface of maneuver sharing and coordination services: internal or external adversaries may be malicious or rational, active or passive, local or extended, direct or indirect. Concrete misbehavior classes include false-location injection, bogus object or sub-maneuver reports, session hijacking, denial-of-service negotiation through repeated reject responses, and time-warp manipulation of start and end times. Proposed detectors include kinematic plausibility checks with false-positive probability

$(t_{\text{start}}, t_{\text{end}})$1

overlap consistency checks on spatio-temporal TRR intersections, CUSUM-based reject-flood detection, and time-consistency audits on startTime and endTime. Mitigations include ECDSA-256 signatures, certificate-based PKI, strict ASN.1 decoding, range checks, sequence and session checks, sensor cross-validation, multi-peer consistency checks, misbehavior reports, revocation lists, and a two-phase commit handshake for high-risk maneuvers (Monteuuis et al., 2022). In ETSI ITS-G5 realizations, RMCS also inherits ITS-Sec mechanisms for authentication, integrity, and pseudonymization (Arockiasamy et al., 7 May 2026).

Open research questions in RMCS now extend beyond link reliability. Aggregate-programming prototypes note that high-density networks may incur broadcast storms, that dynamic obstacles are not captured by static gradient and require continuous recomputation, and that there is no formal SLA on supremely worst-case convergence under adversarial message loss (Audrito et al., 8 Apr 2026). Broader multi-robot coordination research identifies three trends directly relevant to RMCS: resilient coordination, risk-aware coordination, and Graph Neural Networks based coordination policies. Resilient consensus under adversarial neighbors can be achieved with W-MSR filtering on $(t_{\text{start}}, t_{\text{end}})$2-robust graphs satisfying $(t_{\text{start}}, t_{\text{end}})$3; risk-aware methods use mean-variance, Value-at-Risk, Conditional VaR, or chance constraints; and learning-based decentralized policies can generalize across team size and topology, but current GNN/RL methods can be spoofed or poisoned (Zhou et al., 2021). A plausible implication is that future RMCS designs will combine mandatory intent-sharing, explicit protocol-level negotiation, resilient recovery, and selective learned policies while retaining hard fail-safe fallbacks and auditable authority boundaries.