MoRoCo: Multi-Operator, Multi-Robot Exploration

• MoRoCo is a unified framework for multi-operator, multi-robot exploration under restricted communication, integrating human interaction into the coordination process.
• It adaptively switches among spread, migrate, and chain modes to optimize exploration efficiency, maintain connectivity, and ensure timely operator updates.
• Experimental results demonstrate improved area coverage and reduced mission times compared to earlier systems, highlighting its practical benefits in constrained environments.

Searching arXiv for papers related to “MoRoCo” and closely named variants to ground the article in the relevant literature. {} MoRoCo is a unified framework for multi-operator, multi-robot coordination, interaction, and exploration under restricted communication. It targets settings such as subterranean exploration, reconnaissance, search-and-rescue, and damaged indoor infrastructure, where communication is limited to short-range ad-hoc exchanges and where human operators must remain meaningfully in the loop despite intermittent, bandwidth-limited connectivity. The framework jointly models exploration, operator mobility, intermittent robot-robot and robot-operator communication, inter-team information exchange, and bilateral operator–robot requests, and it adaptively switches among spread mode, migrate mode, and chain mode through distributed algorithms using only local communication (Tian et al., 11 Aug 2025).

1. Definition, scope, and disambiguation

MoRoCo addresses a problem that prior communication-constrained exploration systems only partially cover: exploration under severe communication limits with active human operators, rather than purely autonomous teams or teams reduced to a static base-station paradigm. The paper’s core claim is that operator interaction requirements and communication constraints are inseparable in realistic deployments. Operators may require timely mission updates, reprioritize or cancel tasks, request live video or teleoperation, and respond to robot-originated requests for confirmation or assistance; conversely, robots may need help recovering from motion or planning failures. MoRoCo formalizes these bilateral requirements as part of the exploration problem itself (Tian et al., 11 Aug 2025).

The framework should be distinguished from several similarly named but unrelated artifacts. MOROCO denotes the MOldavian and ROmanian Dialectal COrpus, a news-text benchmark for Moldavian-versus-Romanian dialect identification and topic classification (Butnaru et al., 2019). RoCoIn denotes Robust Cooperative Inference, a distributed DNN inference method for heterogeneous edge devices (Wang et al., 2024). Tool-RoCo is an LLM benchmark built on top of RoCo for multi-robot cooperation and self-organization; the paper explicitly states that it does not describe “MoRoCo” (Zhang et al., 26 Nov 2025). This suggests that MoRoCo occupies a distinct line of work centered on communication-aware human–multi-robot exploration rather than NLP benchmarking, edge inference, or LLM tool-use evaluation.

2. Problem formulation and system model

The paper considers a large unknown $3$D workspace $\mathcal{A}\subset\mathbb{R}^3$ with no global communication infrastructure and unknown free space and obstacles. There are $K$ teams,

$$\mathcal{T}\triangleq \{\mathcal{T}_1,\cdots, \mathcal{T}_K\},$$

with each team

$$\mathcal{T}_k\triangleq \{h_k\}\bigcup \mathcal{N}_k,$$

where $h_k$ is one operator and $\mathcal{N}_k$ is that operator’s robot fleet. Robots perform onboard sensing, navigation, and mapping, abstracted as

$$\big(M^+_i,\, p^+_i,\, \boldsymbol{\tau}_i\big) \triangleq SLAM\big(p_i,\, p_{g},\, M_i,\,\mathcal{A}\big),$$

while operators do not build maps directly and instead acquire local maps $M_h^k(t)$ through communication with robots (Tian et al., 11 Aug 2025).

Communication is local and quality-dependent: $$(D_i^+, D_j^+) \triangleq Com(D_i, D_j), \text{ if } Qual(p_i,p_j,\mathcal{A}) > \underline{\delta}.$$ The quality function depends on geometry and environment structure, and the planner uses an MLP to estimate $\mathcal{A}\subset\mathbb{R}^3$0 from map geometry and training data collected in similar environments. The true communication in simulation is generated from a separate analytical propagation model, so planning is based on a learned estimate rather than privileged access to the simulator’s radio model. Multi-hop chains are represented as

$\mathcal{A}\subset\mathbb{R}^3$1

which becomes the basis of chain mode.

The global optimization target is stated as minimizing mission completion time while ensuring complete operator knowledge of the explored map and satisfying online request constraints: $\mathcal{A}\subset\mathbb{R}^3$2 where $\mathcal{A}\subset\mathbb{R}^3$3 is the joint plan of all robots and operators, $\mathcal{A}\subset\mathbb{R}^3$4 is the time when all operators know the full map, and $\mathcal{A}\subset\mathbb{R}^3$5 is the set of online requests. A plausible implication is that MoRoCo treats exploration, synchronization, and operator responsiveness as a single coupled planning problem rather than a pipeline of separate modules.

3. Communication topology and interaction requirements

A central structural choice is the use of a hyper-ring graph. Inter-team communication is organized as a ring

$\mathcal{A}\subset\mathbb{R}^3$6

with $\mathcal{A}\subset\mathbb{R}^3$7 and $\mathcal{A}\subset\mathbb{R}^3$8. Within each team, robots form a ring

$\mathcal{A}\subset\mathbb{R}^3$9

This graph keeps communication sparse, local, and distributed while still guaranteeing periodic information flow between neighboring robots and neighboring teams (Tian et al., 11 Aug 2025).

MoRoCo’s interaction model is unusually explicit. The framework formalizes seven request types grouped into operator-to-robot, robot-to-operator, and inter-team requirements. The operator-to-robot requests are: timely team updates $K$0, prioritized or avoided regions $K$1, operator movement $K$2, and direct remote access, teleoperation, or video $K$3. The robot-to-operator requests are confirmation $K$4 and assistance $K$5. The team-to-team requirement is an inter-team latency bound $K$6. Collectively,

$K$7

The timely-update requirement is formalized through operator-maintained timestamps

$K$8

and maximum operator-team latency

$K$9

subject to

$$\mathcal{T}\triangleq \{\mathcal{T}_1,\cdots, \mathcal{T}_K\},$$0

Robots maintain timestamp estimates

$$\mathcal{T}\triangleq \{\mathcal{T}_1,\cdots, \mathcal{T}_K\},$$1

tracking what teammates know and what the operator knows. This timestamp bookkeeping is the mechanism that lets local event planning imply the global latency guarantee. The paper emphasizes that MoRoCo does not directly solve a global synchronized schedule; instead, it derives local return-event conditions whose satisfaction guarantees bounded operator update latency.

4. Three coordination modes

MoRoCo operates by adaptive mode switching. Execution begins in spread mode and transitions to migrate mode or chain mode when operator requests, robot requests, or communication constraints make the default exploration regime insufficient (Tian et al., 11 Aug 2025).

Mode	Purpose	Typical trigger
Spread mode	Parallelized exploration with intermittent data sharing	Default exploration regime
Migrate mode	Connected team-wise relocation	Operator must move outside feasible region
Chain mode	Temporary multi-hop high-bandwidth relay	Teleoperation, video, confirmation, or assistance

Spread mode

Spread mode is the default exploration mode. Robots do not stay fully connected; instead, they explore separately, meet intermittently with ring neighbors, exchange local maps, plans, and requests, schedule future pairwise meetings locally, and occasionally send one robot back to the operator. Its communication structure is organized around internal events between intra-team neighbors, return events to the operator, and external events between designated messenger robots from neighboring teams. Robot plans are represented as

$$\mathcal{T}\triangleq \{\mathcal{T}_1,\cdots, \mathcal{T}_K\},$$2

Spread mode uses frontier-based exploration. At meetings, neighboring robots merge maps and jointly plan paths that visit frontiers before the next communication event, subject to latency and inter-team timing constraints. The local coordination routine SpreadMode(.) determines whether a return is needed, optimizes the next internal communication event, decides whether one robot must become an external messenger, and updates plans and timestamp estimates. Requests for prioritized regions $$\mathcal{T}\triangleq \{\mathcal{T}_1,\cdots, \mathcal{T}_K\},$$3 and avoided regions $$\mathcal{T}\triangleq \{\mathcal{T}_1,\cdots, \mathcal{T}_K\},$$4 are incorporated into frontier selection; robot confirmation requests $$\mathcal{T}\triangleq \{\mathcal{T}_1,\cdots, \mathcal{T}_K\},$$5 are handled by opportunistically inserting a return to the operator when the future communication schedule allows it.

Migrate mode

Migrate mode is introduced because bounded-latency exploration implies a bounded reachable region relative to the operator. The paper defines a maximum exploitable area

$$\mathcal{T}\triangleq \{\mathcal{T}_1,\cdots, \mathcal{T}_K\},$$6

where reachable positions satisfy

$$\mathcal{T}\triangleq \{\mathcal{T}_1,\cdots, \mathcal{T}_K\},$$7

If all useful frontiers lie beyond what this latency bound permits, the team can become effectively stuck. Migrate mode performs long-distance team-wise transfer: robots return to the operator, the team moves together while preserving connectivity, and spread mode is reinitialized at the new location. The transition rule is explicit: if an operator’s requested destination $$\mathcal{T}\triangleq \{\mathcal{T}_1,\cdots, \mathcal{T}_K\},$$8 lies within the feasible region $$\mathcal{T}\triangleq \{\mathcal{T}_1,\cdots, \mathcal{T}_K\},$$9, movement is handled inside spread mode; if $$\mathcal{T}_k\triangleq \{h_k\}\bigcup \mathcal{N}_k,$$0, migration is triggered.

Chain mode

Chain mode addresses the opposite communication regime: not low-bandwidth intermittent exchange, but sustained high-bandwidth access between an operator and a designated robot. It supports live video streaming, teleoperation, direct inspection, manipulation support, and robot assistance, fulfilling operator request $$\mathcal{T}_k\triangleq \{h_k\}\bigcup \mathcal{N}_k,$$1 and robot assistance request $$\mathcal{T}_k\triangleq \{h_k\}\bigcup \mathcal{N}_k,$$2. A communication-ensured chain is defined as

$$\mathcal{T}_k\triangleq \{h_k\}\bigcup \mathcal{N}_k,$$3

with $$\mathcal{T}_k\triangleq \{h_k\}\bigcup \mathcal{N}_k,$$4, $$\mathcal{T}_k\triangleq \{h_k\}\bigcup \mathcal{N}_k,$$5, anchors inside the known map, and adjacent anchors satisfying

$$\mathcal{T}_k\triangleq \{h_k\}\bigcup \mathcal{N}_k,$$6

The chain is generated by computing a shortest collision-free path from the robot to the operator and greedily placing anchors as far apart as possible while preserving the communication margin.

Relay assignment minimizes the time until the entire chain is ready: $$\mathcal{T}_k\triangleq \{h_k\}\bigcup \mathcal{N}_k,$$7 with assignment weights

$$\mathcal{T}_k\triangleq \{h_k\}\bigcup \mathcal{N}_k,$$8

The team is then partitioned into a line graph of relay robots and a reduced ring graph for the remaining explorers. This topology switching is one of the framework’s defining ideas: bandwidth-intensive operator access is provided only when needed, without forcing permanent connectivity.

5. Algorithms, guarantees, and computational structure

MoRoCo’s algorithms are distributed at the event-planning level, with one partial exception: in chain mode, relay assignment is solved centrally by the return robot. In spread mode, the paper specifies SpreadMode(.), InterCom(.), and ExterCom(.), as well as a dedicated routine for determining return events. In migrate mode, Spread2Migrate(.) propagates the migration command through the last spread-mode communication round, gathers robots back to the operator, and restarts spread mode after relocation. In chain mode, Spread2Chain(.) propagates the future topology split through intermittent local meetings and updates robot plans according to whether a robot becomes a relay or remains an explorer (Tian et al., 11 Aug 2025).

A technically important feature is that the framework derives local conditions that imply global bounded-latency behavior. The paper states that if, for each return event, the next return occurs before the deadline and the minimum timestamp strictly improves, then the operator-latency condition is guaranteed. This is the core mechanism by which MoRoCo avoids centralized global scheduling while still enforcing $$\mathcal{T}_k\triangleq \{h_k\}\bigcup \mathcal{N}_k,$$9. Similarly, feasible operator motion inside spread mode is restricted to a region $h_k$0 that preserves the feasibility of already-confirmed future meetings and returns.

The reported complexity estimates are modest enough to support online use. Return-event and external-event decisions cost

$h_k$1

where $h_k$2 is the number of map nodes. Next internal communication optimization costs

$h_k$3

where $h_k$4 is the number of frontier candidates in the merged map. Communication-ensured chain generation and chain assignment cost

$h_k$5

where $h_k$6 is the number of nodes on the reference path. The paper argues that these costs remain practical because planning is event-based rather than continuous, frontier detection can be incremental, topological maps can reduce $h_k$7, and chain assignment is small-scale within each team. This suggests that the framework’s scalability depends less on a monolithic global optimization and more on the locality of communication events.

6. Experimental evidence, significance, and limitations

The framework is validated in large-scale human-in-the-loop simulations and hardware experiments implemented in ROS, with occupancy-grid maps in simulation, gmapping, multirobot_map_merge, and a custom RViz GUI. Simulation scenarios include a $h_k$8 building complex, a large cave-like environment around $h_k$9 to $\mathcal{N}_k$0, a contingent-task scenario in a $\mathcal{N}_k$1 office environment, and a large-scale $\mathcal{N}_k$2 heterogeneous/failure scenario with $\mathcal{N}_k$3 teams, $\mathcal{N}_k$4 robots, and $\mathcal{N}_k$5 operators. Hardware experiments were conducted on the first floor of the PKU College of Engineering building, sized $\mathcal{N}_k$6, with $\mathcal{N}_k$7 teams, $\mathcal{N}_k$8 Scout-mini UGVs, and $\mathcal{N}_k$9 Cobot-kit mobile manipulator (Tian et al., 11 Aug 2025).

The quantitative results support several specific conclusions. In single-team experiments with $$\big(M^+_i,\, p^+_i,\, \boldsymbol{\tau}_i\big) \triangleq SLAM\big(p_i,\, p_{g},\, M_i,\,\mathcal{A}\big),$$0 robots and $$\big(M^+_i,\, p^+_i,\, \boldsymbol{\tau}_i\big) \triangleq SLAM\big(p_i,\, p_{g},\, M_i,\,\mathcal{A}\big),$$1 operator, averaged over $$\big(M^+_i,\, p^+_i,\, \boldsymbol{\tau}_i\big) \triangleq SLAM\big(p_i,\, p_{g},\, M_i,\,\mathcal{A}\big),$$2 runs, MoRoCo achieved 100% coverage in all three tested environments, whereas MOROCO-NI reached 75.6% in the $$\big(M^+_i,\, p^+_i,\, \boldsymbol{\tau}_i\big) \triangleq SLAM\big(p_i,\, p_{g},\, M_i,\,\mathcal{A}\big),$$3 building, 80.5% in the $$\big(M^+_i,\, p^+_i,\, \boldsymbol{\tau}_i\big) \triangleq SLAM\big(p_i,\, p_{g},\, M_i,\,\mathcal{A}\big),$$4 cave, and 33.2% in the $$\big(M^+_i,\, p^+_i,\, \boldsymbol{\tau}_i\big) \triangleq SLAM\big(p_i,\, p_{g},\, M_i,\,\mathcal{A}\big),$$5 indoor scenario; CMRE, M-TARE, and JSSP were lower still. The gap between MOROCO-NI and MOROCO is used by the paper to demonstrate the contribution of operator movement, prioritization, and migration. In multi-team experiments, moving from one $$\big(M^+_i,\, p^+_i,\, \boldsymbol{\tau}_i\big) \triangleq SLAM\big(p_i,\, p_{g},\, M_i,\,\mathcal{A}\big),$$6-robot team to two $$\big(M^+_i,\, p^+_i,\, \boldsymbol{\tau}_i\big) \triangleq SLAM\big(p_i,\, p_{g},\, M_i,\,\mathcal{A}\big),$$7-robot teams reduced average completion time from about 539.5s to 487.2s, while overlap depended strongly on the inter-team latency bound $$\big(M^+_i,\, p^+_i,\, \boldsymbol{\tau}_i\big) \triangleq SLAM\big(p_i,\, p_{g},\, M_i,\,\mathcal{A}\big),$$8. Without migrate mode (MO-NM), teams in the large indoor scenario failed to complete exploration and reached only 1873.7 m² coverage; full MOROCO reached 2779.0 m², with mission time 1935.3s and exploration time 1865.2s. Without prioritized regions (MO-NP), overlap increased to 76.6% in the building and 70.7% indoors, compared with 47.0% and 56.2% for full MOROCO. Without external events (MO-NE), inter-team latency rose to 359.0s, 482.7s, and 1030.3s in building, cave, and indoor settings, respectively.

Chain mode also showed low computation overhead in contingent tasks: with $$\big(M^+_i,\, p^+_i,\, \boldsymbol{\tau}_i\big) \triangleq SLAM\big(p_i,\, p_{g},\, M_i,\,\mathcal{A}\big),$$9 teams, $M_h^k(t)$0 robots, and $M_h^k(t)$1 contingent tasks, chain lengths of $M_h^k(t)$2 and $M_h^k(t)$3 were used, average chain computation took about 0.3s, anchor assignment about 0.1s, transition times to chain mode ranged from 16s to 44s, all $M_h^k(t)$4 tasks were completed by 1854s, and complete maps were obtained by operators at 2242s and 2290s. In the hardware deployment, the complete map was obtained after 2500s, the explored area reached 1072 m², each team had 9 return events, maximum intra-team latency was 287s and 263s for the two operators under $M_h^k(t)$5, one inter-team event occurred at 1565s under $M_h^k(t)$6, and overlap was 92 m² (8.6%). Teleoperation tasks further reported chain generation times of 3.1s and 2.8s, transition times of 27s and 26s, and a pick-and-place duration of about 240s.

The paper notes several limitations. Good map merging often benefits from overlap, whereas efficient exploration tries to minimize overlap. Semantic information is only lightly used and could improve prioritization, map merging, and task generation. Human interaction is currently mediated mainly by GUI, touch, and terminal interfaces rather than richer multimodal interfaces. Frontier and communication-point choice remain heuristic, some chain-mode decisions are centrally solved by the return robot rather than fully distributed, and simultaneous many-task chain requests are only partly addressed. These limitations indicate that MoRoCo is not a finished autonomy stack; rather, it is a communication-aware operating framework that unifies bounded-latency exploration, operator supervision, operator mobility, robot assistance requests, inter-team coordination, and temporary high-bandwidth relay under restricted communication (Tian et al., 11 Aug 2025).