Multi-Robot Coordination for Modular Robots in Complex Environments
At Direct Drive Tech, we view multi-robot coordination as the ability of several robots to act as one team rather than simply move side by side. They need to divide a mission, cover different parts of an environment, avoid interfering with one another, and regroup when terrain or payload conditions change. Modular robots add another layer: the team may operate as separate units in one area, dock into a larger body in another, and split again without losing the mission. Coordination therefore has to cover task ownership, movement, and physical configuration at the same time.
For a delivery fleet, a fixed body can create a tradeoff between access through tight spaces and the stability needed for uneven ground or larger loads. Modular multi-robot systems bring physical reconfiguration into that decision. Our D1 platform supports wheel-legged and legged combinations, coordinated operation after separation, and ROS 2-based secondary development. In our D1 m.ulti-form robot application overview, we also describe its use in robotics research, testing, and development. These capabilities lead us to a broader industry question: how should a robot team change its roles and physical configuration as the environment changes?
Why modular robots make coordination a different problem
Modular robots make coordination more complex because joining or separating changes what the team can do, how much space it needs, and which unit is responsible for each task. Two independent units can follow separate routes and work in parallel. After docking, they form a combined body with a different footprint, load distribution, and movement requirements. Task assignments and route plans must reflect that change.
Consider a delivery mission: one unit checks a passage while another waits with the payload. Before regrouping, the application needs to confirm a suitable meeting area and establish which tasks the combined body will perform. If the units later separate, completed work should remain recorded, and each unfinished task needs a clear owner. Communication keeps these records consistent as the team changes configuration.
For projects using our D1 platform, we regard this continuity as a key application design requirement. Our modular hardware supports physical reconfiguration; the software that connects task assignments, movement, and configuration changes requires development and validation for the intended mission.
How modular reconfiguration changes multi-robot coordination
Modular reconfiguration lets a robot team adapt its physical arrangement to different stages of a mission. Separate units can handle suitable tasks in parallel, then join where a combined body better suits the route or payload. The benefit depends on whether that change justifies the time and space needed to meet, dock, and resume work.
Our D1 platform supports combinations of wheel-legged units, legged units, or a mix of the two. Two dual wheel-legged units can work separately on flat ground and combine into a quad wheel-legged configuration for obstacle crossing. This gives a team different ways to organize movement and transport around the conditions along a route.
Task allocation needs to follow these physical changes. When two units join, their individual assignments must be reconciled with the combined body's next task. After separation, each unit needs a clear role and an updated task record. The coordination software therefore has to track both mission progress and the team's current configuration.
Task allocation must account for changing configurations
In a modular delivery scenario, the nearest robot may not be the most suitable one for the next task. We recommend considering capability, distance, battery state, communication quality, current load, and task dependencies when designing allocation software.
| Mission question | Coordination decision | Reason to verify |
| Who should inspect the route? | Assign a unit with the required perception and mobility package. | A fast unit is not automatically the best sensing unit. |
| Who should carry or stabilize the payload? | Choose the unit or combined body with the required load and balance margin. | Payload changes can change the safe route and speed. |
| When should robots regroup? | Reserve a meeting area and a time window before docking. | Unplanned convergence creates path and communication conflicts. |
| What happens if one unit stops? | Keep a fallback role, alternate route, or safe-hold state. | Mission continuity depends on failure-aware allocation. |
Task assignments need to adapt as conditions change. A rougher route, an unavailable sensor, or a robot nearing its operating limit may call for another unit or a combined configuration. The application software needs to track the team's current capabilities and update assignments as needed.
Separated and combined operation create different coordination demands
Separate units can follow different routes and carry out tasks in parallel. Docking changes the team's footprint, turning clearance, and load distribution, so route planning needs to account for the assembled robot and its payload. A passage suitable for individual units may leave too little room for the combined body to turn or move safely.
Our D1 platform supports millisecond-level coordination of force output between connected modules, along with collaboration between separated units. For each application, we recommend defining how the software confirms connection status, uses the correct coordinate references, shares sensor data, and determines which controller can issue movement commands. These transition rules require development and validation for the selected configuration and operating conditions.
Preventing path, action, and task conflicts
Reconfiguration links route, action, and task conflicts. A meeting area is both a shared route space and a place where the team's physical state changes. The application needs to account for which unit has access, whether both units are ready to dock, and who owns the unfinished delivery task. If one unit stops or loses communication, those decisions may need to change together. The practical challenge is keeping movement and task ownership consistent through a configuration change.
Through D1, we provide the modular body, synchronized hardware, and ROS 2 foundation. The project software defines route planning, task scheduling, and recovery behavior for the specific environment. This is the distinction we make between platform capabilities and application development.
What our public D1 demonstrations show
Our modular assembly and separation demonstration showcased D1's assembly, separation, and obstacle-crossing capabilities, alongside examples of short-distance transport and delivery applications. D1 also supports collaboration between separated units.
During our live human-robot performance, D1 carried jar props and moved alongside performers, switching between four wheel-legged and two wheel-legged forms and completing separation and docking actions. The performance brought carrying, movement, and physical reconfiguration together in a shared stage space.
These demonstrations show how our modular platform can adapt its body configuration to different tasks and spaces. For deployment, the complete coordination application needs further validation. Task allocation, conflict avoidance, and consistent mission completion should be assessed through repeated runs under the intended route, payload, and communication conditions.
From modular demonstrations to practical deployment
Our D1 collaboration demonstrations illustrate how multi-robot coordination can include changing the team's physical configuration as well as assigning work. For deployment, our key question remains: can the selected robots and cargo complete the whole route, including regrouping, without exceeding available clearance or losing a reliable shared mission state?
Review our D1 configurations and product specifications and our D1 tutorials, user manual, and development documentation to assess the platform and the application work required for your project.
