Part II: Robot Platforms

Chapter 5: Mobile Manipulation — Combining Arms and Mobility

Written: 2026-08-17 Last updated: 2026-08-17

Overview

The question in this chapter is not “which robot arm is most precise?” It is whether an arm on a mobile base can arrive at the right place, establish the right relation to a workpiece, complete work with two arms, recover from failure, and reach the next mission before power runs out. Mobile manipulation is not navigation plus an arm. It combines two error systems and two time scales into one operating system.

The thesis is that commercial maturity in mobile manipulation cannot be inferred from one successful grasp or a base's maximum speed. A base error of a few centimeters can remove the arm's usable workspace. Lifting an object changes the center of mass and stopping distance. Slow replanning increases intervention. Manual resets prevent paper success from becoming throughput. Navigation, bimanual manipulation, recovery, power, human intervention, and fleet dispatch must therefore meet in the same mission record.

Galbot/Galaxy General, Galaxea Dynamics, and X Square Robot are the locked deep profiles for this chapter [1] [3] [6]. The selection is not an absolute ranking. The companies present different evidence structures: a task-oriented platform emphasizing runtime, a research and deployment platform with detailed developer documentation, and a vertically integrated model-and-robot stack. Funding, legal identity, deployment, media, and WRC fields remain undisclosed or unverified when the evidence cannot resolve them.

After reading this chapter... - You can explain how navigation error propagates into reach, precision, and safety at the end effector. - You can combine dual-arm specifications, base pose, and object estimation into a task-level tolerance budget. - You can compare Galbot, Galaxea, and X Square across the same product, technology, business, and SDK fields. - You can distinguish demonstrations from deployment using intervention, reset, battery, and fleet-orchestration evidence. - You can design a manufacturing pilot with explicit tasks, logs, KPIs, acceptance tests, and safety ownership.

5.1 Navigation and Manipulation Are Not a Serial Pipeline

A conventional diagram says that the robot navigates and then the arm grasps. In a real plant, declaring navigation complete already depends on manipulation. Base position and orientation, lift height, elbow clearance, camera visibility, and the human aisle must enter their allowable ranges together. A navigation target defined as one point may be reachable by the base while leaving the arm unable to work or the robot blocking a doorway. Planning should target a set of manipulation-feasible base poses.

Coupling also runs in the other direction. Base acceleration, braking, and turning stability change between an empty arm posture and a 10 kg object held by two arms. Cable routing and self-collision volumes change as well. A mission planner cannot simply declare navigation complete and transfer authority to an arm. When object state and arm posture change, allowable base speed and path may need to change too.

Mobile ALOHA joined a low-cost bimanual teleoperation rig to a mobile base and showed that imitation learning could perform complex tasks in bounded indoor settings [8]. The central contribution was not merely adding wheels. It recorded synchronized whole-body trajectories for the base and both arms. Yet the study needed task-specific demonstrations, used constrained environments, and lacked touch. Research success under those conditions does not establish product generality.

Coupling point Navigation variables Manipulation variables Joint decision record
Approach Map pose, heading, obstacles, stopping error Workspace, visibility, joint margin Rate of reaching a manipulation-feasible base pose
Grasp Micro-motion, floor slip, base vibration Hand-object pose, force, regrasp First-grasp success and collision-free corrections
Carry Acceleration, turn, braking, aisle width Dual-arm load, object swing, self-collision Drop-free travel and restricted speed
Place Docking error, nearby people, final alignment Insertion or placement tolerance, contact force Completion within tolerance and damage rate
Recover Safe stop, relocalization Secure object, retract arm, retry Automatic recovery and human-intervention time

5.2 From Demo to Deployment: The Hidden Denominator

Mobile manipulation produces compelling long-form demonstrations. A robot crosses a room, opens something, picks an object, and places it elsewhere, creating an impression of generality. Procurement needs the location and treatment of every failure more than one successful take. Did localization fail? Did the base stop outside reach? Did the arms interfere? Who restored the scene after an object fell? These are different engineering problems.

BUMBLE linked high-level reasoning, a skill library, a map, memory, and requests for human help over building-scale missions. Its reported full-task success was below one half, while subtask success and reduced intervention provided additional denominators [9]. The result makes an essential distinction: a long mission can be possible without most missions being completed autonomously. Reporting that boundary is more useful for operations than hiding it.

AutoRT combined autonomous, scripted, and teleoperated collection across multiple robots and months, using language models for task proposals and orchestration [10]. A large episode count demonstrates data operations. It does not replace the success rate of a particular manufacturing task. The important structure was the combination of task generation, safety filters, low-level skills, and human supervision. It should not be interpreted as a foundation model holding unrestricted execution authority.

Question What a demo may show What deployment evidence adds
How autonomous? One continuous behavior Intervention type and minutes; remote versus on-site help
How recoverable? Often absent from success footage Replan, secure object, relocalize, manual reset time
How repeatable? Selected objects and route Success distribution across objects, shelves, lighting, and maps
How long can it work? Operation during a short clip Loaded battery duty cycle, charging queue, thermal limits, shift uptime
How does it scale? One robot Mission queue, aisle conflict, charger contention, version consistency

5.3 Deep Profile I — Galbot / Galaxy General

The Korean rendering is 갤봇/갤럭시 제너럴, the English brand is Galbot / Galaxy General, and the Chinese brand is 银河通用机器人. The official site identifies 北京银河通用机器人股份有限公司, states that it was founded in May 2023, and gives a Beijing Haidian address in its privacy notice [1]. Because “Galbot” collectively refers to the company and its global subsidiaries and affiliates, the contracting entity still requires deal-specific confirmation.

The flagship G1 is a tall, wheeled, bimanual mobile manipulator. Official pages state a height of 173 cm, reach up to 2.4 m, IP54 protection, and 275 TOPS of onboard compute [1] [2]. The morphology seeks to cover floor-to-high-shelf work, carry larger objects with two arms, and use wheels for energy-efficient mobility. Height and maximum reach do not mean that every point in that envelope is a usable task pose. Joint configuration, load, self-collision, and camera view reduce the practical workspace.

Galbot's G1 page explicitly states 5kg per arm and 10kg total, but it presents conflicting runtime figures: eight hours in feature copy and 10h in the specification block [2]. Neither runtime should be treated as the sole current value until the vendor resolves the conflict. These are issuer specifications, not an independent duty-cycle test. The evidence does not define how eight hours divide among standby, unloaded travel, bimanual loading, and compute, or at what extension and speed five kilograms can be carried continuously. The figures are acceptance-test inputs, not throughput guarantees.

The technical position combines high vertical reach, two arms, omnidirectional mobility, and onboard perception and compute in one work platform. The official G1 specification block lists Isaac Sim and MuJoCo support. The evidence still does not establish a public SDK, official ROS or ROS 2 packages, Isaac Lab support, downloadable external models, a validated version matrix, or a support lifecycle. Lack of public evidence does not prove absence. It means the integration path is not verifiable from the source set. A buyer should request API documentation and a version matrix in due diligence.

Funding, revenue, audited shipment volume, and active installed base are undisclosed or unverified in the captured evidence. Product specifications establish productization intent, not customer acceptance, mean time between failures, or cost per task. Maturity is therefore “a commercialization-oriented platform with official product specifications,” not “large-scale repeat deployment.”

Profile field Evidence-bounded record
KO / EN / CN name 갤봇·갤럭시 제너럴 / Galbot·Galaxy General / 银河通用机器人
Foundation and headquarters Official brand verified; foundation date, current legal entity, and legal headquarters unverified
Flagship products G1 wheeled bimanual mobile manipulator
Technology High vertical reach, dual-arm manipulation, omnidirectional mobility, onboard perception and compute
Disclosed finance and traction Funding, revenue, and audited shipments undisclosed; 5kg per arm/10kg total is an issuer specification, while runtime conflicts between eight hours and 10h
Maturity Product and official specifications verified; customer-level long-duration operation and repeat deployment unverified
SDK, ROS, Isaac Public SDK, official ROS/ROS 2, Isaac support, and version matrix unverified
Media-corpus visibility Unmeasured because a complete eligible-article export is unavailable
WRC 2026 status Official exhibitor directory verifies booth C104; program participation remains unverified
Strengths High workspace with dual arms and wheels, designed around long operating duration
Limitations Missing duty-cycle conditions, developer ecosystem evidence, independent uptime, and business metrics
Evidence confidence Medium-low: official product record exists; legal, financial, SDK, and deployment verification is limited

The planned official product photograph should show G1 working between a high shelf and a low bench, with both arms visible from the side. A useful image exposes base width, lift structure, arm-interference volume, and sensors. It does not resolve the conflicting eight-hour/10h runtime statements or prove sustained five-kilogram work.

Figure 5.1: A retail-shelf task scene from Galbot's official G1 product page. It shows the spatial relationship among the wheeled base, lifting torso, both arms, and high and low shelves, but does not establish an eight-hour duty cycle, sustained five-kilogram work, or repeatability. Source: Galbot G1 product page, fair use for academic review

5.4 Deep Profile II — Galaxea Dynamics

The Korean rendering is 갤럭시아 다이내믹스, the English brand is Galaxea Dynamics, and the official Chinese legal name is 星海图(北京)人工智能科技股份有限公司. The company page reports a September 2023 foundation [3]. The Chinese entity name establishes a Beijing operating basis, but the evidence does not fully resolve a legal headquarters address and every affiliate. The profile records “Beijing-based; detailed headquarters unverified.”

The portfolio includes R1 Pro, R1, and R1 Lite mobile manipulators, A1 and A1-X arms, teleoperation hardware, and EDP and GForge development platforms. R1 variants combine an omnidirectional base, lifting torso, two arms, cameras, and lidar [4]. Pro, standard, and Lite balance degrees of freedom, sensors, payload, data collection, and deployment differently. Buyers need a model-by-software-by-duty-cycle record, not a blended family specification.

Galaxea reports a two-meter vertical workspace and up to five kilograms per arm at a 0.5-meter condition for R1 [4]. These are issuer specifications under its own test conditions. The lift range does not imply constant bimanual load or repeatability at every height, and maximum payload may differ from continuous rated load. Acceptance should test residual vibration after base or lift motion and simultaneous use of both arms.

The developer ecosystem is among the most concrete of the three profiles. Official documentation supports SDK combinations for Ubuntu 20.04 with ROS 1 Noetic and Ubuntu 22.04 with ROS 2 Humble. It exposes arm, torso, chassis, camera, lidar, IMU, battery, autonomous-navigation, and teleoperation interfaces [5]. This supports module-level diagnosis and synchronized data collection. NVIDIA Jetson AGX Orin appears in product specifications, but official Isaac Sim or Isaac Lab validation is not established by the evidence.

The current company page reports nearly 100 global customers and says four financing rounds within one year brought cumulative financing near US$100 million under issuer definitions [3]. Retaining the older “40+ direct customers” split requires a dated archived source. These figures are not independently audited for paid status, overlap, product mix, activity, or round closing. They indicate the direction of business traction; they are not converted into shipment volume or recurring revenue.

Profile field Evidence-bounded record
KO / EN / CN name 갤럭시아 다이내믹스 / Galaxea Dynamics / 星海图(北京)人工智能科技股份有限公司
Foundation and headquarters Founded September 2023; Beijing basis verified, detailed legal headquarters unverified
Flagship products R1 Pro, R1, R1 Lite; A1 and A1-X arms; teleoperation; EDP and GForge
Technology Omnidirectional base, lifting torso, dual arms, synchronized sensing, teleoperation, data and post-training tools
Disclosed finance and traction Company reports near US$100 million cumulative funding and nearly 100 global customers; the older 40+ direct-customer split requires a dated archive
Maturity Multiple products, SDKs, support, and warranty structure verified; customer uptime and task success undisclosed
SDK, ROS, Isaac ROS 1 Noetic and ROS 2 Humble SDKs with module interfaces verified; official Isaac support unverified
Media-corpus visibility Unmeasured because the eligible-article count is incomplete
WRC 2026 status Official exhibitor directory verifies booth C210; program participation remains unverified
Strengths Detailed documentation and SDKs, product variants, connected teleoperation and data collection
Limitations Issuer-defined business metrics, incomplete bimanual duty-cycle and independent uptime evidence
Evidence confidence Medium: strong product and SDK evidence; finance, customer, and deployment numbers are issuer-reported

The planned official product photograph should show R1 Pro or R1 linking floor, bench, and shelf work through its lifting torso and both arms. A separate detail may show the omnidirectional base and sensor ring. Photography should explain morphology and interfaces, not stand in for the customer or uptime denominator.

Figure 5.2: Real product photography from Galaxea Dynamics' official R1 Pro unboxing guide. The shipping case and secured robot expose delivery and maintenance interfaces, but do not establish workspace, payload, customer deployment, or field success. Source: Galaxea Dynamics R1 Pro unboxing guide, fair use for academic review

5.5 Deep Profile III — X Square Robot

The Korean rendering is 엑스스퀘어 로봇, the English brand is X Square Robot, and the Chinese company name is 自变量机器人科技有限公司. The English site's footer identifies X Square Robot Technology (Shenzhen) Co., Ltd. and a Shenzhen address; the company chronology records a December 2023 foundation and launch of Shenzhen operations [6]. It also names research and operations centers in multiple cities. This profile records Shenzhen as the headquarters-like operating base while treating group-entity mapping as partial.

Flagships include the Quanta X1 Pro wheeled bimanual research platform, Quanta X2 wheeled humanoid, ArtiXon Hand, and the WALL-A and WALL-OSS model line [6]. The strategy co-designs sensors, arm degrees of freedom, teleoperation, data collection, and robot hardware around model needs. Vertical integration can shorten model-hardware iteration, but documentation and licenses must show which layers an external customer can replace.

X Square reports 19 degrees of freedom, a three-kilogram rated payload, 250 Hz teleoperation, and a 1.6-meter vertical workspace for Quanta X1 Pro [7]. These issuer specifications lack independent uptime evidence. A 250 Hz command rate is not end-to-end perception-network-control latency; arm rated payload differs from whole-body task payload; and the full workspace does not imply uniform precision.

Official product documentation states pre-integration with WALL-A, native ROS 2 support, multi-language APIs including Python, and data-acquisition tools [7]. Model and training-code releases are also described. The evidence does not establish an official NVIDIA Isaac model, extension, or validated version matrix. ROS 2, SDKs, and an open model create a strong entry surface, but they do not automatically expose safety-critical low-level control or define commercial support.

The company chronology lists several financing rounds and expansion milestones, but authoritative closing documents do not resolve overlap, paid-in amount, post-money ownership, or audited revenue [6]. The rounds are therefore not summed. Official descriptions of complex tasks and logistics deployment also omit customer-level task counts, success, intervention-free time, and paid acceptance. Deployment maturity remains partial.

Profile field Evidence-bounded record
KO / EN / CN name 엑스스퀘어 로봇 / X Square Robot / 自变量机器人科技有限公司
Foundation and headquarters Founded December 2023 with Shenzhen operations; official Shenzhen address, partially resolved group structure
Flagship products Quanta X1 Pro, Quanta X2, ArtiXon Hand, WALL-A and WALL-OSS
Technology VLA-world-model integration, wheeled bimanual body, high-rate teleoperation, co-designed data, model, and hardware
Disclosed finance and traction Company chronology lists multiple large rounds; overlap, close, and audited revenue unverified, so no aggregation
Maturity Product documentation and deployment descriptions exist; customer acceptance, uptime, and recurring economics unverified
SDK, ROS, Isaac ROS 2, multi-language API, Python SDK, and WALL releases verified; official Isaac support unverified
Media-corpus visibility Unmeasured because the defined corpus has no complete export
WRC 2026 status Official exhibitor directory verifies booth C107; program participation remains unverified
Strengths Vertical model-data-teleoperation-body loop with public developer entry points
Limitations Independent validation of issuer performance, finance, deployment, and long-duration uptime remains thin
Evidence confidence Medium: product and developer sources are concrete; business and deployment evidence is partial

The planned official product photograph should place Quanta X1 Pro's two arms, lift range, sensors, and base in one work scene. A useful image includes the object, aisle, and docking relation rather than only a WALL-A interface. Success in one frame remains a case, not a repeatability denominator.

Figure 5.3: A shelf-carrying scene from X Square Robot's official Quanta X1 Pro product video. It places both arms, the lift, wheeled base, and task objects in one frame, but does not establish 250 Hz end-to-end latency, repeatability, or customer deployment. Source: X Square Robot Quanta X1 Pro product video, fair use for academic review

5.6 Comparing the Three on the Same Scale

The common morphology is a human-like upper body on a wheeled base, targeting a large vertical workspace and bimanual coordination. The evidence focus differs. Galbot foregrounds G1 body specifications and runtime. Galaxea exposes multiple variants and detailed SDK and ROS documentation. X Square links WALL models, teleoperation, ROS 2, and its own body into one learning loop.

Field evidence for mobile manipulation must include navigation, recovery, power, human intervention, and fleet interfaces in addition to a successful arm action [8] [9] [10]. Strong performance in one layer still leaves the other layers able to bottleneck order-level completion.

Comparison axis Galbot / Galaxy General Galaxea Dynamics X Square Robot
Product focus G1 with high reach and long runtime target R1 Pro/R1/Lite, arms, and development platforms Quanta X1 Pro/X2 and WALL models
Dual arm and base 5kg per arm/10kg total claimed; runtime conflicts between eight hours and 10h, while precision and duty cycle remain unverified Omnidirectional base, lift, and model-specific payload documents 19 DoF, three kilograms, 250 Hz, and 1.6 m are issuer specs
Developer ecosystem Public scope unverified ROS 1/2 SDKs, module interfaces, teleoperation ROS 2, Python and multi-language SDKs, model and data tools
Business evidence Funding, revenue, and shipments undisclosed Issuer customer and funding counts, not audited Multiple issuer-reported rounds, no aggregation or audit
Deployment reading Product-oriented, missing long-duration field denominator Product and support structure, missing customer uptime Complex-task claims, missing acceptance and uptime
Priority diligence SDK, docking precision, loaded battery duty cycle Rated versus maximum load, version support, customer metrics Low-level safety authority, model updates, funding and deployment records

The table does not choose a winner. A lab reproducing papers may weight ROS documentation. A team developing a proprietary foundation model may weight teleoperation and model access. A two-shift factory will prioritize rated load, charging, repair time, docking error, and contractual acceptance. The decisive issue is the riskiest unknown under the intended use, not a universal company score.

5.7 Navigation-Manipulation Coupling: Pose Is Workspace

Final base error does not merely add to end-effector error. A few degrees of heading error produce larger lateral error at the end of a long arm and change the camera view. A moving torso may alter cable load, inertia, and camera extrinsics. Reading map localization and arm repeatability as independent specifications and adding them is not enough.

A practical planner creates a region of manipulation-feasible base poses around an object and selects one that preserves aisle use and human clearance. If the object moves or the shelf differs, the system must choose between correcting with the arm and moving the base. Reduced arm margin makes base correction attractive, but base motion during contact can destabilize force control. Authority-transfer rules must be explicit.

Bimanual work adds a moving temporary frame. When one arm supports an object and the other manipulates it, the object relates base, both arms, hands, and fixture. Transform estimates need a shared clock and calibration version. A five-millimeter extrinsic-camera error may be acceptable for grasping yet fail connector insertion. Tolerance budgets should be task-specific.

5.8 Intervention and Reset: Turning Failure into Operable Data

Human intervention is not an embarrassing exception to autonomy. It is an operational resource to design. The system needs rules for requesting help, transferring authority to a remote operator, allowing an on-site worker to approach, and returning to autonomous mode. Asking too late damages parts and equipment; asking too early consumes the labor savings.

Human-in-the-loop task and motion planning assigns only planner failures to a person and uses interventions as training data [12]. AnyTeleop and DexPilot show a lineage of retargeting human arm and hand motion across robot forms [13] [14]. Occlusion, missing haptics, latency, and infeasible poses still make remote decisions difficult. Teleoperation is a recovery and data interface, not a guarantee.

Reset is a frequently hidden cost. If a person spends three minutes restoring an object, standing a tote up, retracting the arms, and relocalizing after a thirty-second task failure, effective throughput collapses. Success must be reported with reset time per failure, people required, object or equipment damage, and the fraction of failures that return automatically to a reusable mission state.

Figure 5.4: BUMBLE's accounting of 70 reported trials, split into 32 successes and 38 failures, with failures further categorized as VLM reasoning, depth, segmentation, and lidar issues. This is a task- and platform-specific denominator, not a comparison among companies. Source: Shah et al. 2024, arXiv:2410.06237 Fig. 6, CC BY 4.0
Intervention type Trigger Required log Signal of automation improvement
High-level question Goal, object, or route ambiguity Observation, candidate plans, question, answer Fewer repeated questions in the same state
Remote fine control Grasp or insertion error crosses threshold Latency, human command, force, image, transition time Shorter remote segment and fewer retries
On-site recovery Drop, collision, blockage, communications loss Safety event, object state, access time More automatic securing and relocalization
Full reset State leaves the mission graph Restoration actions and labor Higher proportion of local recovery

5.9 Dual-Arm and Base Precision: Speak in Tolerance Budgets

An “arm repeatability of one millimeter” cannot by itself support an assembly claim. Base docking, torso lift, camera calibration, object pose, gripper play, load deflection, and inter-arm calibration all contribute. Treating them as independent and taking a root-sum-square can also be wrong under contact. Directional bias and thermal drift may accumulate in the same direction.

Bimanual tasks require relative and absolute precision. Two arms calibrated well to each other may carry a large object while still missing a fixture hole in an external frame. An external camera may locate the fixture precisely while poor force sharing twists the object. Acceptance should separate unloaded paths, single-arm load, shared dual-arm load, and contact insertion.

Base precision also changes with infrastructure. A system docking to a visual marker or reflector is not being tested under the same condition as markerless navigation. In manufacturing, a small environmental modification may cost far less than developing general perception. Rejecting markers for the sake of generality can be irrational; total economics and maintenance ownership should decide.

5.10 Energy and Fleet Orchestration

Battery duration must be converted into a mission-energy model. Travel distance, base acceleration, lift cycles, arm load, onboard compute, idle time, and communications all consume energy. G1's eight-hour and 10h statements conflict, and neither separates patrol from loaded bimanual duty. Dispatch should use voltage sag, temperature, predicted mission energy, and safe reserve to a charger—not percentage alone.

With multiple robots, shared-resource conflict may dominate individual capability. Aisles, elevators, docking points, chargers, remote operators, and staging areas require reservations. The closest robot is not necessarily the right robot. Tool and hand configuration, battery, policy version, map, payload, and maintenance schedule all matter.

A foundation model can describe missions and propose actions, but separate layers should check feasibility, collisions, force, battery, traffic, and authority. AutoRT's value was not a single model autonomously commanding a fleet. It combined task proposals, skill selection, safety filters, human supervision, and conventional control in a large collection operation [10]. Orchestration is a problem of authority and state consistency as much as model inference.

Orchestration state Required fields Failure when wrong
Robot readiness Battery, temperature, tool, policy, map, faults Charging exit mid-mission or incompatible action
Resource reservation Aisle, dock, charger, elevator, remote operator Deadlock, long queues, competing intervention requests
Mission priority Due time, safety, energy, workpiece validity Nearest robot delays the important order
Version consistency Model, SDK, firmware, map, calibration Same command produces different behavior
Failure handling Isolation, substitute robot, object handoff, rollback One failure stops the entire cell

5.11 Manufacturing Walkthrough — Lineside Kit Replenishment

Consider replenishing two types of kit boxes from several supermarket shelves to a rack beside an assembly line. Boxes differ in size and mass, and some need two arms. People and AMRs cross the aisle. Empty rack slots change throughout the shift. Value comes from delivering the correct kit, undamaged and on time—not from peak robot speed.

First, build a task-state graph: receive order, confirm inventory location, reserve route, approach shelf, align base, verify code and geometry, choose single- or dual-arm grasp, retreat, carry, recheck rack, place, update inventory, and proceed to the next mission or charger. Attach a failure code and recovery authority to every transition. Replace “failed to pick” with occluded view, unreachable pose, slipping grasp, base misalignment, or wrong item.

Second, construct a tolerance budget. Measure shelf-map error, base docking, camera extrinsics, box-pose estimation, gripper center, inter-arm calibration, and rack-slot error. Do not ask arm precision to absorb the largest term. Choose among floor markers, shelf reference faces, mechanical guides, and better calibration based on the cheapest system-level reduction.

Third, design data and intervention. Include empty slots, misplaced or crushed boxes, human blocking, AMR crossings, low battery, and one-arm faults—not only normal picks. When a remote operator takes authority, record why and timestamp the transition between autonomous and human commands. Include the time an on-site worker spends restoring the box in task cost.

Fourth, couple energy and dispatch. Use mission distance, box mass, charge queue, and peak-shift orders to size the fleet and chargers. Prevent a low-energy robot from starting a heavy bimanual mission. Define a safe handoff state for a box carried by a failed robot. A nominal battery duration does not establish two-shift operation.

Fifth, divide acceptance into nominal, variation, and fault-injection tests. Nominal trials measure throughput and quality. Variation trials change lighting, friction, and box pose. Fault injection covers communication loss, sensor occlusion, charger outage, and gripper error. KPIs include order-level completion, wrong-kit rate, damage, intervention-free time, automatic recovery, human minutes, charging wait, and total cost per task.

Pilot decision Initial boundary Gate before expansion
Items Two kit types on known shelves Detect variation, misplacement, and empty slots
Navigation One aisle with marker-assisted docking allowed Safe stop and resume around people and AMRs
Manipulation Single arm plus one bimanual box Meet grasp, carry, and placement tolerance under load
Intervention and reset Log remote help and on-site recovery Meet target human minutes and full-reset fraction
Energy One charger and supervised dispatch No charging deadlock during peak orders
Safety and ownership Segregated pilot and physical emergency stop Approved risk, version change, and incident-recovery responsibility

Manufacturing Cell Checkpoint

The task schema should include object ID and lot, mass, dimensions, fragility, allowed grasp faces, source and destination slots, due time, human and AMR priority, and a safe object state after failure. Navigation, perception, single-arm, dual-arm, and handoff authority change inside one mission, so transitions and timeouts must be explicit.

Logs should connect base pose and covariance, wheel slip, lift position, both arms' joints and torque, gripper state, camera and lidar time, object pose, battery and temperature, mission queue, and human intervention under one execution ID. Success videos alone cannot locate the error layer. Pre- and post-recovery state and reset work belong to the same mission.

KPIs extend arm success into order completion. Measure correct item, quantity, slot, and deadline; replenishments per hour; continuous intervention-free time; human minutes; wrong items; object and equipment damage; energy; charging wait; and mean recovery time. Examine the worst ranges by shift, serial number, and item, not only a pilot average.

Ownership spans manufacturing engineering, logistics, safety, IT and security, data and models, and the supplier. Manufacturing owns tolerance and task. Logistics owns aisle priority. Safety owns protective stops and human access. IT owns maps, networks, and updates. The data team owns policies and logs. The supplier owns firmware, parts, and repair. Model updates must not bypass acceptance; change approval and rollback are mandatory.

5.12 Limitations and Open Questions

The first limitation is unequal corporate and financial disclosure. Galaxea and X Square describe funding and customers on official pages, but those sources are not audited statements. Missing Galbot values do not equal zero. The atlas leaves undisclosed fields blank and does not upgrade issuer claims into independent verification.

The second limitation is test conditions behind product specifications. Runtime, maximum payload, workspace, and teleoperation rate do not describe one simultaneously achieved duty cycle. Battery, thermal behavior, and precision need testing while carrying a heavy object with both arms, moving the lift and base, and running onboard models.

The third limitation is the demo-to-deployment gap. Long official videos discover capabilities but may omit total attempts, resets, remote support, customer acceptance, and uptime. Papers are also bounded by task and platform. BUMBLE's failure denominator and AutoRT's supervision structure produce more useful procurement questions than a success reel alone.

The fourth limitation is media visibility and WRC 2026. No complete eligible-article count exists for the defined period and outlet set, so all three companies remain unmeasured. The official exhibitor directory verifies Galbot at C104, Galaxea at C210, and X Square at C107; program participation remains unverified for all three. A visit plan should recheck the directory and on-site signage [15].

The fifth limitation concerns simulation scope. SimFoundry shows promise in reconstructing simulation scenes and variants from real video for policy evaluation and data generation, but current evidence is concentrated in a limited set of manipulation tasks and flat support scenes [11]. It does not establish reliable automatic reconstruction of multi-floor navigation, thresholds, elevators, and human traffic.

Relation to Prior Surveys

Chapter 4 asked about locomotion, production, and ecosystem at the body level. Mobile manipulation tests the general-purpose promise in a narrower operational unit. Many tasks may not need legs; a human-like upper body on wheels can improve energy efficiency and stability. If stairs and rough terrain are essential, however, the apparent simplicity disappears.

Task-and-motion planning historically connected symbolic goals to continuous trajectories. Teleoperation and imitation learning turned human whole-body solutions into data. Foundation models now extend high-level task interpretation and skill selection. In a plant, feasibility, contact, stop authority, and human handoff must remain explicit. Language competence does not replace base-docking tolerance or bimanual force balance.

What to Learn Next

Mobile manipulation promises generality, but the factory productivity baseline still comes from fixed industrial arms and collaborative robots. Chapter 6 examines platforms that reduce mobility while increasing repeatability, speed, safety certification, integration tools, and maintenance maturity. A mobile robot must justify itself against that baseline through flexibility or lower reconfiguration cost.

Carry three questions into Chapter 6. Is mobility truly necessary, or could fixtures, conveyors, and fixed arms simplify the task? How are shared-workspace safety and force limitation validated? Is retraining a general model cheaper than traditional teaching and process engineering? The contest is not for more degrees of freedom. It is for converting the variation created by those degrees of freedom into productivity.

References

  1. Galbot (2026a). Galbot official overview. Official company website.
  2. Galbot (2026b). Galbot G1 specification. Official product website.
  3. Galaxea Dynamics (2026a). Galaxea official profile. Official company website.
  4. Galaxea Dynamics (2026b). Galaxea R1 product documentation. Official product documentation.
  5. Galaxea Dynamics (2026c). Galaxea developer documentation. Official SDK and ROS documentation.
  6. X Square Robot (2026a). X Square Robot and WALL-A. Official company website.
  7. X Square Robot (2026b). Quanta X1 Pro specification. Official product website.
  8. Fu, Z., Zhao, T. Z., and Finn, C. (2024). Mobile ALOHA: Learning Bimanual Mobile Manipulation with Low-Cost Whole-Body Teleoperation. arXiv:2401.02117.
  9. Shah, R. et al. (2024). BUMBLE: Unifying Reasoning and Acting with Vision-Language Models for Building-Wide Mobile Manipulation. arXiv:2410.06237.
  10. Ahn, M. et al. (2024). AutoRT: Embodied Foundation Models for Large Scale Orchestration of Robotic Agents. arXiv:2401.12963.
  11. Ranawaka, N. et al. (2026). SimFoundry: Modular and Automated Scene Generation for Policy Learning and Evaluation. arXiv:2606.28276. #85
  12. Mandlekar, A. et al. (2023). Human-in-the-Loop Task and Motion Planning for Imitation Learning. CoRL 2023.
  13. Qin, Y. et al. (2023). AnyTeleop: A General Vision-Based Dexterous Robot Arm-Hand Teleoperation System. RSS 2023. DOI: 10.15607/RSS.2023.XIX.015.
  14. Handa, A. et al. (2020). DexPilot: Vision-Based Teleoperation of Dexterous Robotic Hand-Arm System. ICRA 2020, arXiv:1910.03135.
  15. World Robot Conference (2026). World Robot Conference official website. Official organizer source.
  16. John Schulman et al. (2014). Motion Planning with Sequential Convex Optimization and Convex Collision Checking. DOI:10.1177/0278364914528132.
  17. Michael Posa et al. (2014). Planning Through Contact: A Unifying Approach to Manipulation. DOI:10.1177/0278364913506757.
  18. Ioan A. Șucan et al. (2012). The Open Motion Planning Library. DOI:10.1109/mra.2012.2205651.
  19. Sertac Karaman et al. (2011). Sampling-Based Algorithms for Optimal Motion Planning. DOI:10.1177/0278364911406761.
  20. Mrinal Kalakrishnan et al. (2011). STOMP: Stochastic Trajectory Optimization for Motion Planning. DOI:10.1109/icra.2011.5980280.
  21. Leslie Pack Kaelbling et al. (2011). Task and Motion Planning in the Now. DOI:10.1109/icra.2011.5980391.
  22. Rosen Diankov (2010). OpenRAVE: A Planning Architecture for Autonomous Robotics. Carnegie Mellon University PhD thesis.
  23. Nathan Ratliff et al. (2009). CHOMP: Gradient Optimization Techniques for Efficient Motion Planning. DOI:10.1109/robot.2009.5152817.
  24. Dmitry Berenson et al. (2009). Manipulation Planning on Constraint Manifolds. DOI:10.1109/robot.2009.5152399.
  25. Peter F. Hokayem et al. (2006). A Survey of Bilateral Teleoperation and Telepresence. DOI:10.1017/s0263574705002053.
  26. James J. Kuffner et al. (2000). RRT-Connect: An Efficient Approach to Single-Query Path Planning. DOI:10.1109/robot.2000.844730.
  27. Steven M. LaValle (1998). Rapidly-Exploring Random Trees: A New Tool for Path Planning. Iowa State University technical report.
  28. Lydia E. Kavraki et al. (1996). Probabilistic Roadmaps for Path Planning in High-Dimensional Configuration Spaces. DOI:10.1109/70.508439.
  29. Dale A. Lawrence (1993). Stability and Transparency in Bilateral Teleoperation. DOI:10.1109/70.258054.
  30. Günter Niemeyer et al. (1991). Stable Adaptive Teleoperation. DOI:10.1109/48.64895.
  31. Rodney A. Brooks (1986). A Robust Layered Control System for a Mobile Robot. DOI:10.1109/jra.1986.1087032.