STARFAB Mobile Inspection Module (MIM)

• STARFAB MIM is a modular robotic inspection pod designed for on-orbit evaluation of hardware health and condition assessment without disassembly.
• It integrates multi-modal sensors—visible imaging, 3D structured-light, and thermal—to perform precise non-destructive testing under extreme space conditions.
• Its reconfigurable mobility leverages standardized interconnects and manipulator support to enable rapid deployment and targeted light maintenance tasks.

STARFAB Mobile Inspection Module (MIM) is the dedicated inspection-and-light-maintenance element of the STARFAB orbital servicing hub, a project aimed at demonstrating an orbital automated warehouse or depot for sustainable in-space servicing, assembly, and maintenance. Within that architecture, the MIM is a self-contained module responsible for monitoring the health and condition of both stored hardware and the hub itself. Its function is not generic robotics, but targeted inspection, condition assessment, and support for limited maintenance interventions in an on-orbit warehouse environment that is autonomous or semi-autonomous, minimally controlled, vacuum-exposed, irradiated, and thermally extreme (Wang et al., 18 Jul 2025).

1. Operational role within the STARFAB hub

The MIM is designed around four operational problems. First, STARFAB must inspect modular spacecraft payloads and all externally accessible surfaces without disassembly. Second, it must assess impact, scratch, deformation, and thermal anomalies on Orbital Replacement Units (ORUs), hosted spacecraft, docked servicing spacecraft, and the servicing facility structure. Third, it must monitor the facility continuously enough to support lifecycle analysis, damage detection, and failure prediction using non-destructive testing (NDT). Fourth, it must support basic planned and unplanned maintenance, though not complex repair operations, because full robotic maintenance on orbit remains fundamentally difficult (Wang et al., 18 Jul 2025).

This definition places the MIM between a pure sensor payload and a general-purpose servicing robot. The paper characterizes it as a modular robotic inspection pod with onboard perception and limited maintenance support. Inspection is the primary function; maintenance is secondary and deliberately constrained. The intended targets include all payload external surfaces, hosted spacecraft exteriors, ORUs in transit, STARFAB structural elements, and docked servicers. The requirement set quantified in the paper includes automated NDT for all payload external surfaces, hosted spacecraft external inspection without disassembly, scratch or deformation damage detection from debris larger than $0.3 \, \text{mm}$, debris impact damage detectable down to $0.6 \, \text{mm}$ diameter, and $90\%$ probability of detection at $95\%$ confidence (Wang et al., 18 Jul 2025).

The concept is tied to the broader STARFAB view of modular orbital servicing. Multiple MIMs can be warehoused within STARFAB and deployed as operations require. This modular storage-and-retrieval logic is central to the subsystem’s role: the MIM is meant to be summoned where sensing is needed rather than remaining a fixed inspection station (Wang et al., 18 Jul 2025).

2. Mechanical form and modular architecture

Mechanically, the MIM is a modular body derived from the form factor of the Multi-Arms Robot (MAR) torso previously developed for on-orbit large telescope assembly. The design went through three major iterations, beginning from a standalone cuboid ORU concept and ending in a configuration aligned with the MAR torso. By adopting the MAR torso form factor, the MIM can reuse an established kinematic and mechanical integration scheme already compatible with the wider STARFAB robotic system, thereby reducing integration risk and improving interoperability (Wang et al., 18 Jul 2025).

The final layout is described as a hexagonal shape with unequal sides. A sensor package is mounted on one of the longer sides in a cylindrical-like enclosure capable of tilt motion. This gives the module a distinct front sensing face, while side and rear locations remain available for manipulator interfaces. The body combines a central chassis with tool storage compartments and a front sensor enclosure. Tools are stored in open-sided compartments on two sides of the main body beneath a lid, and those compartments extend both internally and externally relative to the original MAR torso profile as a compromise between reducing interference between the Walking Manipulators (WMs) and tools while still carrying enough tooling capacity (Wang et al., 18 Jul 2025).

A key architectural feature is the use of three HOTDOCK Standard Interconnects (HD/SI) mounted at the corners of the chassis. These Standard Interconnects are the principal mechanical, electrical, and system integration interfaces to the rest of STARFAB. The three connectors can interface to WMs, payloads, and other modular components, and their number and placement are selected to support multiple operational configurations. The authors explicitly note that the evenly distributed three-HD arrangement improves flexibility when paired with WMs: two interconnects can be used for mobility or positioning, while a third can remain available for tool interaction or other interfaces (Wang et al., 18 Jul 2025).

The architecture is therefore modular in two senses. At the body level, the MIM is a self-contained element with its own power and processing resources. At the system level, it behaves like a reconfigurable node within a larger orbital servicing infrastructure. The paper does not give complete external dimensions or total mass for the final unit, but it states that mass reduction is a major design concern and that the flight version is larger and heavier than comparable ground applications (Wang et al., 18 Jul 2025).

3. Mobility, positioning, and deployment configurations

The paper calls the MIM an “independently-mobile robot,” but its mobility is not free-flying propulsion-based locomotion or internal wheeled or crawling actuation. Instead, mobility is achieved through integration with WMs and the Standard Interconnect network. In one configuration, two WMs attach to the MIM and operate as “legs,” allowing it to walk across infrastructure attachment points. In another, the MIM is a payload mounted on a WM that is itself mounted to a shuttle or fixed point. In another configuration, the MIM is carried by STARFAB’s external Large Arm using a grapple fixture and positioned over an inspection site. A further configuration fixes the MIM at a structure attachment point and uses it as an “eye-in-hand” or, more precisely, a remotely positioned sensor pod (Wang et al., 18 Jul 2025).

This mobility model is best understood as system-level relocatability. The module is not permanently tied to one manipulator or one station, yet its physical relocation depends on manipulator assets and fixture networks. The paper frames this as a deliberate tradeoff: by offloading locomotion to existing WMs and attachment networks, the design avoids adding propulsion, reaction control, or complex crawling mechanisms to the inspection package itself, which would increase mass, power, complexity, and likely contamination risk. The cost is corresponding dependence on the availability of manipulator assets and structural fixture points (Wang et al., 18 Jul 2025).

A plausible implication is that the MIM can be read as an orbital analogue of reconfigurable inspection nodes discussed in manufacturing research. Reconfigurable Inspection Systems are defined as inspection capabilities designed from the outset for rapid change in structure and in hardware/software, with modular sensing, configurable fixturing, and adaptable computation; their design features include modularity, rapid convertibility, customized flexibility, and scalability (Gupta et al., 2023). The STARFAB MIM paper does not use RMS or RIS terminology, but its combination of interchangeable interfaces, reassignable deployment, modular sensors, and responsive software closely resembles that logic. In that sense, mobility functions less as locomotion in isolation than as one mechanism for rapid inspection reconfiguration.

The primary use case is inspection of ORUs and modular spacecraft components while they are being transported to or from the primary structure, so that inspection can occur without obstructing the main structure. Secondary use cases include inspection of STARFAB’s own structural integrity, both internally and externally, and inspection of docked servicer spacecraft. The module is therefore operationally versatile: it is not simply a fixed camera box, but a relocatable robotic inspection payload that can be placed where sensing is needed (Wang et al., 18 Jul 2025).

4. Sensor suite, NDT functions, and inspection workflow

The baseline payload spans RGB imaging, 3D surface reconstruction, point-cloud generation, and thermal imaging. The paper identifies three principal sensing modalities: high-resolution visible imaging, 3D profilometry, and thermal imaging, while also stating that additional modular sensors can be added (Wang et al., 18 Jul 2025).

For visible inspection, the requirements specify a high-resolution machine vision camera with an encircling illumination unit. In the implementation section, the authors explain that a camera with zoom lens and local image processing capability is preferred so objects remain sharp at different distances. For compatibility with the onboard computer and ROS2 middleware, the prototype solution uses Raspberry Pi 5 processors with Pi Camera 3 sensors mounted at the four corners of the front panel of the sensor enclosure. This four-corner placement broadens the effective field of view and helps see around potential obstructions when inspecting cluttered external hardware, ORUs in transfer, or structural interfaces. The paper also notes ring-topology visible-spectrum illumination as a requirement, because optical inspection in orbit cannot rely on stable ambient light and must cope with strong contrasts and varying sun angles (Wang et al., 18 Jul 2025).

For high-resolution surface shape measurement, the MIM uses a 3D structured-light scanner rather than lidar. The authors explicitly state that most lidar units have insufficient point cloud density for sub-millimetre surface profiling, so they selected a Matter and Form THREE 3D structured-light camera system. The rationale is directly tied to the detection requirements: STARFAB requires detection of scratches or deformation damage from debris larger than $0.3 \, \text{mm}$, and impact damage down to $0.6 \, \text{mm}$ diameter, with $90\%$ probability of detection at $95\%$ confidence. The structured-light scanner is intended to generate detailed mesh or point-cloud models of target surfaces for profilometry, deformation analysis, and fine NDT. The paper includes an initial readout image showing a generated mesh model from the 3D scanner, confirming that geometric reconstructions were already being produced in early prototype form (Wang et al., 18 Jul 2025).

For thermal inspection, the selected sensor is a Waveshare long-wave infrared thermal imaging camera with $80 \times 62$ resolution. The thermal sensing requirement is to distinguish localized temperatures from $-40^\circ \text{C}$ to $0.6 \, \text{mm}$0. Its role is coarse-resolution anomaly screening rather than fine geometric defect detection: identifying hot spots, failed units that are colder than expected, abnormal thermal patterns, or localized heat associated with malfunction (Wang et al., 18 Jul 2025).

These sensors are integrated in a dedicated front sensor enclosure. The inspection workflow implied by the paper is sequential and multimodal. The MIM is first positioned by one or more WMs, a shuttle, or the Large Arm to obtain suitable line of sight to the target. Visible cameras with illumination provide contextual imagery and broad visual coverage; if needed, the structured-light scanner acquires dense geometric data for surface profiling; the thermal imager acquires a temperature map to identify thermal anomalies. The requirements indicate an inspection range from $0.6 \, \text{mm}$1 to $0.6 \, \text{mm}$2, so the system must support both close-up defect inspection and more distant situational monitoring (Wang et al., 18 Jul 2025).

5. Computing, software integration, and maintenance support

On autonomy and software, the paper provides a limited but informative description. For terrestrial testing, the onboard computing platform is an Nvidia Jetson Orin Nano developer board running Linux. It was selected because it can run image and signal processing algorithms in real time and supports hardware acceleration for sensors. The software environment uses ROS2 over Ethernet as the system bus to communicate with other components, and the development stack includes OpenCV for machine vision, the Point Cloud Library (PCL) for 3D data handling, and the InFuse Common Data Fusion Framework (CDFF) for robotics data fusion (Wang et al., 18 Jul 2025).

This implies a modular, message-oriented software architecture with sensor acquisition, vision processing, point-cloud processing, and fused perception distributed across ROS2-connected components. At the same time, the paper is explicit about what is not yet described: it does not provide detailed autonomy levels, state machines, localization algorithms, navigation planners, mission planners, control loops, or formal supervisory control logic. There are no explicit descriptions of onboard SLAM, target tracking, path planning, or defect classification pipelines beyond the statement that the prototype will be used for algorithm development to meet inspection performance requirements (Wang et al., 18 Jul 2025).

The MIM also supports light maintenance through tool storage and manipulator cooperation. Two tools are specifically identified: a grasping tool and a torque wrench. These are stored within the modular body and are not directly actuated by the MIM itself; instead, an attached WM retrieves and manipulates them. The maintenance mode uses an additional WM mounted to one of the available Standard Interconnects, so that the tool can be accessed while the MIM’s sensing package observes the operation. In this arrangement, the WM’s own integrated camera acts as an “eye-in-hand” sensor, while the MIM sensor package serves as an “eye-to-hand” sensor, giving complementary visual viewpoints for manipulation (Wang et al., 18 Jul 2025).

The maintenance envelope is deliberately narrow. The requirements table specifies that the gripper tool must grasp objects from $0.6 \, \text{mm}$3 to $0.6 \, \text{mm}$4 in dimension, and that the torque tool must be compatible with a NASA Pistol Grip Tool type interface over a torque range of $0.6 \, \text{mm}$5 to $0.6 \, \text{mm}$6. This indicates handling of small replacement items and standardized fastening operations rather than heavy-duty structural assembly (Wang et al., 18 Jul 2025).

Power and communications are described more briefly. Internal electronics are said to operate at $0.6 \, \text{mm}$7 and consume approximately $0.6 \, \text{mm}$8 per unit, except for the onboard computer and illumination source, which consume more. The robotic arm power bus operates at $0.6 \, \text{mm}$9, allowing more efficient distribution with a current limit of around $90\%$0 for the entire robot. While the MAR uses up to $90\%$1 peak power, the MIM is estimated to consume up to $90\%$2 at maximum operating capacity. The exact power architecture is not fully described, but Standard Interconnect compatibility and robotic arm power buses are clearly central (Wang et al., 18 Jul 2025).

6. Development status, evidence, and place in inspection research

The paper is explicit that implementation and testing were still ongoing at the time of writing. What had already been implemented included the mechanical design concept, a prototype sensor enclosure with integrated perception electronics, a Jetson-based onboard computing setup, selected visible, 3D, and thermal sensors, and initial data acquisition. Figures show the prototype in 3D, front, and top views, as well as a 3D-scanner-generated mesh model and an RViz2 screenshot visualizing sensor outputs. The next stated step was to test the complete prototype in identifying and profiling ORUs and STARFAB structural elements as a platform for algorithm development needed to achieve performance requirements. After verification, the authors planned a MIM with aluminium chassis and near-flight-capable components for the STARFAB demonstration in mid-2026 (Wang et al., 18 Jul 2025).

Equally important are the missing validations. The paper does not present final integrated performance results for inspection accuracy, defect detection probability, autonomous task completion, tool-use success, or end-to-end on-orbit operational readiness. There are no reported closed-loop mobility tests with WMs carrying the MIM, no quantified maintenance task trials, no verified thermal anomaly detection performance, and no demonstrated compliance with the detection requirements in the table. The current status is therefore prototype and subsystem integration with early sensor outputs, not full system qualification (Wang et al., 18 Jul 2025).

In a broader research context, the STARFAB MIM occupies a distinctive position. It is not a factory-floor inspection robot, yet it shares several properties with reconfigurable inspection literature: modular sensing, scalable payload composition, non-contact optical metrology, and integration of physical hardware with a cyber layer (Gupta et al., 2023). What distinguishes it is the orbital servicing setting and the decision to realize mobility through manipulator infrastructure rather than self-propelled locomotion. This makes the MIM less a stand-alone rover than a networked inspection-and-maintenance element embedded in a larger robotic warehouse.

Taken as a whole, the MIM is best understood as a modular robotic inspection pod designed for deep interoperability with the STARFAB hub. Its mobility is infrastructural rather than self-propelled; its inspection capability is built around complementary visible, geometric, and thermal sensing; its maintenance function is limited to simple grasping and fastening tasks executed by attached WMs; and its current evidentiary basis remains that of a credible prototype rather than a validated operational system (Wang et al., 18 Jul 2025).