---
title: 'MoonBot: Modular Lunar Robotics'
url: https://www.emergentmind.com/topics/moonbot
type: topic
---

# MoonBot: Modular Lunar Robotics

MoonBot is a modular and on-demand reconfigurable robotic system for lunar surface operations and moon base construction, engineered to maximize functionality while operating within the stringent mass constraints of lunar payloads and adapting to varying environmental conditions and task requirements. The platform combines heterogeneous functional modularity in hardware with what its software architecture paper terms distributed, heterogeneous modularity in software, communication, and deployment. Across the current literature, MoonBot is presented as a self-assembling and reconfigurable system for civil engineering operations, infrastructural component transportation and deployment, assistive operations with inflatable modules, autonomous alignment during assembly, and compatibility with a modular bucket drum excavator for lunar ISRU [2512.21853] [2511.01437].

## 1. System concept and module taxonomy

MoonBot’s hardware design is organized around specialized modules rather than strictly identical units. The design philosophy is described as heterogeneous functional modularity: modules are specialized, optimizing the trade-off between flexibility, performance, and operational simplicity. The core modules are a **Limb module**, a **Wheel module**, a **Body module**, and a **Hand module (gripper)** [2512.21853].

| Module | Description | Stated role |
|---|---|---|
| Limb module | Symmetrical 7-DOF articulated arm with a gripper at each end | Can serve as an arm or leg |
| Wheel module | Dual-motor, independently driven base | High-speed locomotion |
| Body module | Central hub with battery and computer | Grapple fixtures for module interconnection |
| Hand module | 1-DOF parallel jaw | Object grasping and connecting modules |

Each module is described as self-contained, with power, compute, and sensors. Modules are transported as compact units and assembled *in situ* on the lunar surface. The resulting morphologies are task-specific. A **Minimal configuration** consists of 1 Limb + 1 Wheel; a **Vehicle configuration** uses 1 Limb + 2 Wheels; a **Dragon configuration** joins 2 Minimals in series to improve traction and load capacity; and a **Multicycle configuration** places multiple Minimals in parallel for heavier payloads and redundancy [2512.21853].

This organization is explicitly tied to lunar mission constraints. The modular architecture allows multiple task profiles to be fulfilled with a single stowed kit of modules, while heterogeneous modules place multi-DOF capability only where useful. The papers therefore distinguish MoonBot from purely clone-modular or single-purpose rover concepts: reconfiguration is intended to support transportation, manipulation, infrastructure deployment, civil preparation, and assistance to deploy inflatable modules within one platform family [2512.21853].

## 2. Reconfiguration mechanisms and connector design

MoonBot’s reconfiguration workflow includes **on-palette self-assembly**, in which modules are fixed to a launch palette and a Limb module, acting as a robotic arm, sequentially assembles itself with Wheel or other Limb modules to form the desired configuration. This process is central to the claim of on-demand reconfiguration, because the robot is not merely re-tasked in software; it is reconstituted physically into different morphologies [2512.21853].

Three connector types are described. The **parallel jaw gripper** is used mainly for MoonBot and is essential both for module assembly and general manipulation. The **screw-type connector** is gendered, 3D printed, and robust for structural joints. The **diaphragm-type connector** is genderless and allows quick, flexible coupling without strict alignment, although with slightly less connection strength. Connector sensing is implemented with infrared sensors in the gripper and at grapple points for reliable wireless detection of successful connections; the first prototype does not yet include a physical signal or power bus [2512.21853].

The parallel jaw gripper is reported with a **maximum opening of 80 mm** and a **pinch force of 2.1 tons**. Its sliding mechanism uses polyacetal (POM) for low friction and dust exclusion, and a trapezoidal screw converts BLDC motor rotary motion to jaw linear motion. For the screw-type connector, the reported lesson is that critical tolerancing is needed for passive self-alignment during assembly. For the diaphragm-type connector, the reported lesson is improved usability for self-reconfiguration and maintenance, but also a need for improved alignment protocols, with visual servoing and 2D markers identified as a possible remedy [2512.21853].

The lessons learned are materially important. Parallel jaw grippers and screw connectors were mechanically robust, successful in field tasks, and tolerant to mild misalignments. At the same time, sand and dust ingress were identified as a significant risk, especially for connectors with exposed screws or hatches. Future iterations are described as likely to incorporate improved sealing and possibly power and signal transfer across connections. This suggests that, in MoonBot, modularity is not treated as a purely geometric docking problem; it is also a contamination, sensing, and maintainability problem [2512.21853].

## 3. Software architecture, communication, and deployment

MoonBot’s control software is the **Motion Stack**, described as hierarchically modular, distributed, and aware of different module types and configurations. In the hardware-oriented paper, the control hierarchy is organized into five levels: **Level 1: Individual joint control**, **Level 2: Inverse kinematics target computation**, **Level 3: Manage limb trajectories**, **Level 4: Synchronize multi-limb**, and **Level 5: Operator input, flexible mapping to subsystems**. Teleoperation is primarily via joystick and keyboard, with visual feedback from wrist-mounted and field cameras. The reported joint controller is a “clamped integral” controller,
$$
u_k = \max\!\left(y_k - \delta_e,\ \min \left( y_k + \delta_e,\ u_{k-1} + \dot{r}_k (t_k - t_{k-1}) \right)\right),
$$
where \(u_k\) is the position command, \(\dot{r}_k\) is the input velocity, \(y_k\) is the current joint measurement, and \(\delta_e\) is the maximum allowed error. The stated fail-safe property is that, if communication is lost, joints do not move [2512.21853].

The software-architecture paper generalizes this into a broader framework of **distributed, heterogeneous modularity**, extending modular robotics beyond physical reconfiguration to software, communication, and orchestration. Its component structure separates **Core**, **Injection/Override**, **API**, **Interface**, **Executor**, and **Communication** blocks, with hardware- and robot-specific code isolated from the main logic. Communication is explicitly data-centric rather than node-centric, using ROS2 with Zenoh as middleware in place of DDS. The paper reports lower startup times and bandwidth requirements, better stability at **10+ robots/modules vs. 4 maximum for DDS**, and faster connectivity recovery when switching from DDS to Zenoh [2511.01437].

Deployment is handled by an orchestrator that manages version control, build, assembly-specific configuration, and process launch. Its **Robot Assembler** computes kinematics, URDFs, host- and hardware-specific settings, and per-module calibration for a given assembly; its launcher starts only the required processes for each hardware node. The reported operator interface reduces routine deployment to three actions per robot: `update`, `build`, and `start`. In field deployment, the system supported **multiple robot families + 7 module types**, assemblies with **>60 live ROS2 components**, and routine assembly changes reduced from **1-2 weeks** to **20 seconds** [2511.01437].

These software results matter because MoonBot is presented not merely as a modular mechanism, but as a modular robotic system that must scale across time, hardware, teams, and operational environments. The platform’s architectural claim is that dynamic reconfiguration, decentralized control, self-assembly, inter-robot cooperation, and remote operation become operationally manageable only when hardware modularity is matched by communication and deployment modularity [2511.01437].

## 4. Autonomous alignment for self-assembly

For autonomous assembly and reconfiguration, MoonBot is paired with an **agnostic end-effector alignment controller** that does not rely on robot-specific kinematics, joint sensing, or force feedback. The controller uses only measured end-effector pose \((x_e, q_e)\) and measured target pose \((x_t, q_t)\), as provided by external vision or motion-capture systems. Its raw pose errors are defined as
$$
\Delta d = \|x_t - x_e\|, \qquad
\Delta\theta = 2 \arccos\left(|q_t^{-1} \cdot q_e|\right).
$$
Translational and rotational bounds are then interpolated from the current error magnitude and modulated by shrink factors \(f_j\), \(f_k\), and \(f_s\), yielding effective bounds \(\Delta_t^{\rm eff}\) and \(\Delta_r^{\rm eff}\). The controller clamps the combined translational and rotational command to a 6D ellipsoidal hypersphere,
$$
u =
\begin{bmatrix}
v_{\rm raw}/\Delta_t^{\rm eff} \\
\omega_{\rm raw}/\Delta_r^{\rm eff}
\end{bmatrix},
\qquad
\hat u = \frac{u}{\max(1,\|u\|)},
$$
and outputs
$$
v_c = \hat u_{1:3}\,\Delta_t^{\rm eff}, \qquad
\omega_c = \hat u_{4:6}\,\Delta_r^{\rm eff}.
$$
A low-pass filter is applied to prevent abrupt changes between controller ticks [2510.21164].

Two controller variants are reported. **Version 1** is a discrete step-and-settle controller that issues a small pose increment and waits for stabilization before proceeding. **Version 2** is a continuous velocity controller that applies the adaptive hypersphere clamp at every tick. Both were implemented without modification on two different 7-DOF MoonBot limbs in JAXA’s lunar environment simulator, using only external pose feedback from OptiTrack motion capture at **180 Hz**, and validated on **MoonBot Minimal** and **Dragon** assembly targets [2510.21164].

| Version / Limb | Duration | Final errors |
|---|---:|---|
| Version 1 (Limb V1) | \(92.9 \pm 1.98\) s | \(5.93 \pm 0.14\) mm, \(0.35 \pm 0.04^\circ\) |
| Version 2 (Limb V1) | \(57.86 \pm 8.23\) s | \(4.51 \pm 0.64\) mm, \(0.59 \pm 0.07^\circ\) |
| Version 1 (Limb V2) | \(52.00 \pm 4.18\) s | \(8.78 \pm 0.83\) mm, \(0.34 \pm 0.31^\circ\) |
| Version 2 (Limb V2) | \(46.83 \pm 2.63\) s | \(4.57 \pm 0.77\) mm, \(1.49 \pm 0.62^\circ\) |

The qualitative comparison is explicit. Version 1 produced highly smooth, monotonic motion with minimal lateral wobble and little to no oscillation. Version 2 converged more quickly, typically reducing alignment time by **20–25%**, and generally outperformed Version 1 in translation at minor cost to final orientation accuracy, which remained sub-degree. Both versions remained robust under substantial imperfections, including up to **10° joint backlash** and **10 cm flex/wobble**, which is directly relevant to self-assembly under lunar-relevant disturbances [2510.21164].

## 5. Excavation as an ISRU payload

MoonBot is also presented as a carrier and integration platform for lunar excavation hardware. The bucket drum excavator paper describes a tool developed for MoonBot as part of the **Japanese Moonshot program**, with a centrally located mechanical interface on the shaft between two drum assemblies so that it can attach to MoonBot’s arm modules. The excavator uses **two drums**, each with **four pairs of opposing spiral-shaped buckets** spanning **160°**, and the buckets are rotationally offset so that only one bucket engages regolith at a time. The stated purpose is to minimize instantaneous mechanical loads and reaction forces, a low-gravity consideration. Felt seals are used at moving interfaces to reduce dust ingress, and the prototype is primarily PLA, with gears and structural parts reinforced by carbon fibers [2511.00492].

The prototype tool weighs **4.8 kg** and has a **volume of 14.06 L**. Reported actuation consists of a **24 V, 50 W EC motor (Maxon)**, a **936:1 ceramic planetary gearhead**, and a maximum drum speed of **~7.5 rpm**, controlled by a **Maxon EPOS4 Disk 60/8 driver** in **Profile Velocity mode**. The integrated **Dragon configuration** has a total system mass of **95 kg**, including the MoonBot platform. Validation was performed in a **3 m × 4 m sandbox** with **Tohoku Silica Sand**, **8 cm deep**, using both hand-operated and MoonBot-operated trials [2511.00492].

| Mode | Excavation rate | Normalized energy consumption |
|---|---:|---:|
| Continuous excavation | \(777.54\ \text{kg/h}\) | \(0.022\ \text{Wh/kg}\) |
| Batch operation | \(172.02\ \text{kg/h}\) | \(0.86\ \text{Wh/kg}\) |

Additional reported metrics clarify the performance envelope. In continuous mode, the volumetric rate is **0.53 m\(^3\)/h**, average power draw is **~16.74 W**, and the operation time to material-loss threshold is **~46 s per cycle at full fill**. In batch operation, the reported cycle breakdown is **46.08 s at 146.74 W** for excavation, **23.3 s at 144.13 W** for unloading, and **138.89 s at 150 W** for driving **10 m @ 0.14 m/s**. The limiting factor is stated to be transit time and process overheads outside raw excavation. Capacity measurements report a **maximum mass load of 12.87 kg**, an **operational (no loss) mass load of 9.95 kg**, and filling efficiencies ranging from **62%** at max fill for the drum only to **32%** at onset of loss when all buckets are included. The design is described as **comparable to NASA RASSOR 2.0** in continuous and batch excavation rates and in low normalized energy use [2511.00492].

The significance for MoonBot is architectural as much as mechanical. The excavator is characterized as a removable payload compatible with the modular platform, enabling alternative ISRU mission scenarios such as mobile excavators depositing regolith at a staging point while a dedicated transport rover shuttles material to processing sites. Future improvements are stated to include force and torque sensors, fill-level or material-mass sensing, autonomous control for depth-of-cut regulation and full-cycle autonomy, structural redesign for lunar vacuum and thermal cycling, and the use of FEM and DEM for further design iteration [2511.00492].

## 6. Demonstrations, performance envelope, and lessons learned

The principal field demonstration reported for MoonBot took place at the **JAXA Advanced Facility for Space Exploration** in a **20 m × 20 m** analog field of silica sand, with additional environments containing actual regolith simulant, over **three weeks continuous testing**. Operation was primarily teleoperated, while on-palette assembly was semi-automated. The milestone tasks were construction-oriented: on-palette assembly of robots, mobility and traversability tests, rock and boulder removal, terrain leveling, transport and deployment of infrastructure, and assistive operations for inflatable habitat deployment [2512.21853].

The demonstrated mobility envelope depends on morphology. Minimal, Vehicle, Dragon, and Multicycle configurations were tested. The system demonstrated adaptive locomotion through wheel–limb collaboration, slope climbing up to **20°**, and traversal of sandy and rough terrain. In civil engineering tasks, the Dragon configuration used its front limb as a manipulator for rock removal, while a Minimal configuration transported sleds. Terrain leveling was performed with a raking tool and wrist-mounted camera feedback. For infrastructure handling, a Dragon configuration transported and deployed an extendible **>30 kg tower** representing a solar or communications mast, and collaborative operations were used to erect and manipulate panel-type components [2512.21853].

The assistive habitat deployment scenario further broadens the claimed operational scope. In that task, a Dragon configuration monitored inflatable module inflation with a hand-eye camera, checked for leaks via pressure feedback, and placed restraint stoppers to stabilize the pressurized module after deployment. Separate durability tests at **DLR/ESA LUNA** reported reliable operation for **3 days** in a high-dust environment, including descending and ascending crater terrain with **10°–20° slopes** [2512.21853].

The reported hardware performance figures include **2 kg at full limb extension** for each module under Earth gravity, scaling to **>12 kg on lunar gravity**, **>2 tons** grip force at the end effector, **480 mm wheels**, and **30 kg payload capacity** for the wheel module. Connection success was reported as high for gripper and screw-type connectors, while the diaphragm-type connector required higher precision in alignment but improved notably with visual feedback. In parallel, the software-architecture paper reports months of field deployment with self-assembling robots, inter-robot cooperation, and remote operation, including teleoperation across WiFi, internet, cellular 5G, and back to WiFi with negligible added architectural or operational complexity [2512.21853] [2511.01437].

Taken together, these results position MoonBot as a modular robotic system for lunar infrastructure rather than a single fixed robot. The literature emphasizes that the central challenge is not only physical reconfiguration, but also the coordinated design of connectors, control, communication, orchestration, and task-specific payloads. A plausible implication is that MoonBot’s primary research contribution lies in treating lunar construction robotics as a problem of system-level modularity across hardware, software, and operations rather than as a problem of locomotion or manipulation in isolation.

Source: https://www.emergentmind.com/topics/moonbot