Chapter 11: Medical, Consumer, and Specialized Robots — Breadth of Commercialization

Overview

The question in this chapter is: How should buyers compare robots whose evidence is produced under radically different regulatory, environmental, and commercial regimes? A surgical robot may be legally marketed for a named indication after regulatory review. A quadruped may carry an IP rating and cross rubble in a manufacturer video. A public-facing humanoid may dance for a crowd or be preordered as an experience platform. These facts are meaningful, but they are not interchangeable measures of safety, reliability, clinical benefit, autonomy, or business maturity.

The thesis is that commercialization breadth must be evaluated as a chain of bounded claims. Medical robotics needs device- and jurisdiction-specific authorization, trained users, clinical governance, sterile workflows, and outcome evidence. Specialized field robotics needs environmental qualification, communications resilience, recoverability, maintainability, and mission-level denominators. Consumer-facing robotics needs understandable limits, safe interaction, privacy controls, support capacity, content operations, and a cost model that survives after the novelty fades. The correct comparison therefore asks what was authorized, tested, delivered, used, maintained, and economically renewed—not whether all three machines look impressive on video.

MicroPort MedBot, Deep Robotics, and LimX Dynamics are the three locked deep profiles in this chapter ^{[1] [7] [14]}. They represent a regulated surgical portfolio, special-environment legged platforms, and developer-to-consumer-facing general-purpose embodiments. They are not ranked on a single capability score. Each is assessed against the evidence regime of the market it asks a buyer to enter.

After reading this chapter... - You can separate regulatory clearance, clinical evidence, engineering qualification, field reliability, and commercial traction. - You can read orders, installations, procedures, missions, active sites, and shipments as different denominators. - You can evaluate field robots through communications loss, energy, payload, recovery, service, and mission completion rather than a highlight reel. - You can distinguish a consumer-facing experience product from a mass-market household product and identify the operations behind both. - You can construct acceptance tests and service agreements that match the consequences of failure.

11.1 Three Markets, Three Evidence Regimes

“Robot” is a hardware category, not one market. In surgery, the patient, indication, clinical team, accessory set, and jurisdiction define the operating claim. A regulator may permit marketing after reviewing a dossier, but the authorization does not establish superiority over every alternative. Hospital adoption adds procurement, credentialing, training, maintenance, sterilization, incident reporting, and health-economic review. A robot can be commercially mature while a new procedure, accessory, or remote mode remains early.

In a substation, mine, tunnel, petrochemical site, disaster zone, or mountain trail, approval gives way to mission assurance. Dust and water ingress, temperature, slopes, steps, shock, electromagnetic conditions, communications shadows, payload balance, battery aging, and operator extraction determine whether a platform returns useful data. A laboratory maximum speed or slope is a boundary measured under stated conditions. It is not a probability that a full inspection mission will finish.

Consumer and public-experience robots face a third contract. People may touch the machine without training, move unpredictably, record it, or expect conversational competence that the product does not have. Venues need content updates, charging, floor supervision, crowd control, network fallback, cleaning, storage, and rapid replacement. A preorder price verifies an offer at a date; it does not prove delivery volume, retention, utilization, or profitable support.

The evidence objects should remain separate. A regulatory certificate attaches to a device and intended use. An IP rating attaches to a tested enclosure configuration. A financing announcement describes an issuer-reported transaction. An order records commercial intent under an undisclosed contract. An installation records placed hardware. A procedure or mission records use, but only a denominator, follow-up window, failure definition, and intervention policy reveal performance.

11.2 An Evidence Ladder for Commercial Robots

The lowest useful rung is identity: legal entity, product configuration, declared purpose, and source date. Product pages and organizer listings are suitable here. The next rung is component or laboratory specification, with test conditions and tolerances. Integrated demonstrations then show that a configured system can perform a sequence at least once. A controlled benchmark adds trials, failures, resets, and a baseline. A customer pilot adds real operators and workflow constraints. Routine deployment adds time, utilization, service, and repeated exposure. Independent outcome or field evidence adds the strongest external check.

Issuer evidence is not useless. It is often the only current source for product configuration, interfaces, launch dates, prices, and commercial milestones. The error is to silently transform its scope. “IP67” should remain an issuer-published product specification unless the test laboratory and report are available. “Installed” should not become “routinely used.” “Successful remote implementation” should not become “better clinical outcome.” “Thousands of orders” should not become audited shipments or revenue.

Time alignment matters. A company can report 100 installations in one release and a higher number in a later annual report. Combining the newest order count with an older installation count creates a synthetic snapshot that never existed. This chapter uses dated claims and states when the unit of account changes. It also distinguishes a parent-company annual report from segment-level statements, because consolidated revenue is not the revenue of every named product.

Safety evidence is application-specific. ISO 12100 provides a general machinery risk-assessment and risk-reduction framework ^[21]. Collaborative industrial-robot guidance such as ISO/TS 15066 concerns a different application boundary and cannot be pasted onto a surgical system, field quadruped, or public humanoid as if it certified the whole product ^[22]. The durable method is hazard identification, risk estimation, layered reduction, verification, residual-risk communication, and change control.

11.3 Deep Profile I — MicroPort MedBot

The Korean rendering is 마이크로포트 메드봇, the English brand is MicroPort MedBot, and the Chinese legal name is 上海微创医疗机器人（集团）股份有限公司. The English legal form used by the company is Shanghai MicroPort MedBot (Group) Co., Ltd. The company says the program began as internal incubation at MicroPort in 2014 and the entity was established in China in 2015. Its disclosed address is in Zhangjiang Hi-Tech Park, Shanghai ^[1]. “Founded” therefore needs two dates: technology development in 2014 and corporate establishment in 2015.

The flagship portfolio spans laparoscopic, orthopedic, panvascular, percutaneous, trans-natural-orifice, and related surgical tracks. Named systems include Toumai for laparoscopic surgery, SkyWalker for orthopedic surgery, R-ONE for intervention, Mona Lisa for prostate biopsy, and DFVision for three-dimensional endoscopy ^[2]. A portfolio label does not mean every product is authorized in every country or for every procedure. The exact model, accessory, software version, indication, and jurisdiction must be read from the applicable regulator and labeling.

Toumai integrates a surgeon console, patient-side robotic arms, imaging, instruments, and software into a teleoperated surgical system. The technology proposition includes dexterous instrument control, tremor filtering, three-dimensional visualization, motion scaling, ergonomic separation of surgeon and patient, and, in selected configurations, remote operation. These are system capabilities around clinician control; they are not evidence that the platform independently decides a procedure. Clinical authority remains with credentialed professionals and hospital governance.

MicroPort's 2025 reporting says Toumai had obtained certifications or approvals in more than 60 countries and regions cumulatively ^[4]. This is meaningful regulatory traction, but “60+” is an issuer-aggregated geographic count. Every jurisdiction, device version, indication, accessory, remote-use claim, and current certificate still requires verification in the relevant regulator's database or official labeling. The count must not be read as sixty identical authorizations or as comparative clinical superiority.

The same report describes nearly 300 cumulative orders and nearly 200 installations across the surgical-robot segment at its reporting date. It reports segment revenue of US$77.6 million, or RMB 551.1 million, in 2025, an increase of 114.2% year on year on its stated basis; overseas revenue was reported at US$56 million. It also reports improved gross margin and a narrower segment loss ^[4]. These are disclosed public-company financial and traction measures. They do not reveal product-level revenue, hospital utilization, paid versus demonstration placements, cancellation terms, procedure mix, or total cost per case.

Maturity is regulated commercial portfolio with multi-market installations, while maturity remains device- and jurisdiction-specific. Orders, installations, trained teams, procedures, consumable use, and patient outcomes form different layers. The business model plausibly combines capital equipment, instruments and accessories, procedure-linked consumables, training, and service. The annual report notes growth in supporting consumables, but a comparable split of recurring revenue, service margin, instrument utilization, and contract duration is not publicly disclosed.

The developer surface is intentionally unlike an educational robot. No public general-purpose SDK, ROS package, or NVIDIA Isaac integration was verified for the regulated surgical systems. That absence should be recorded as not publicly disclosed, not interpreted as technical incapability. Buyers instead need controlled integration documentation, cybersecurity and update procedures, service interfaces, accessory compatibility, data governance, and regulator-approved change processes. Public research interfaces, if any, must not be confused with the commercially authorized configuration.

Clinical evidence requires multiple endpoints. Procedure completion and conversion, complications, margin or implant accuracy where relevant, blood loss, operating time, length of stay, readmission, learning curve, and longer-term outcomes answer different questions. Remote surgery adds network availability, end-to-end latency, jitter, packet loss, local backup, credentialing across locations, emergency conversion, and responsibility allocation. The company reports hundreds of remote human procedures and a high implementation-success rate; that is issuer evidence of technical and organizational execution, not by itself a comparative patient-outcome result ^[4].

Service support is part of the medical device. A hospital must know preventive-maintenance intervals, parts availability, field-engineer response, software validation, cybersecurity patching, instrument reprocessing, backup capacity, and the contingency if the robot stops after anesthesia begins. Public sources describe commercialization and training, but comparable uptime, mean time to repair, first-time fix, service-level attainment, and cancelled-case rates were not disclosed.

Media-corpus visibility is unmeasured because this chapter did not construct a complete multilingual corpus with a fixed date window and deduplication rule. WRC 2026 status is unverified in the captured current organizer evidence; older show-floor appearances must not be transferred to the 2026 roster. Strengths are a broad regulated portfolio, public-company disclosure, reported international approvals and installations, and an ecosystem that spans several procedural categories. Limits are heterogeneous regulatory scope, limited public product-level economics, issuer-heavy utilization evidence, and no uniform independent clinical comparison across the portfolio.

Confidence is high for legal identity, development history, Shanghai location, named products, and the disclosed annual-report figures; medium for portfolio-level maturity and remote-operating scale; and low to medium for comparative clinical benefit, product-level profitability, uptime, and cross-jurisdiction equivalence. The official product photograph below shows the physical patient-side Toumai robot, but not the complete combination of surgeon console, image cart, authorized accessories, or clinical outcomes.

11.4 Deep Profile II — Deep Robotics

The Korean rendering is 딥 로보틱스, the English brand is Deep Robotics, and the Chinese brand is 云深处科技. Current official materials use 云深处科技股份有限公司, while older English pages use Hangzhou DEEP Robotics Technology Co., Ltd. The company reports that it was founded in 2017 and gives a Hangzhou, Zhejiang address in the Zijin Dream Plaza area ^{[7] [8]}. Entity suffixes and translated names should be tied to the source date rather than forced into one timeless label.

Flagship products include the X30 and X20 industrial quadrupeds, Lite3 research and education quadruped, LYNX M20 wheeled-legged platform, DR01 and DR02 humanoids, and joint modules. The technology stack covers locomotion control, terrain adaptation, perception, navigation, autonomous inspection, payload integration, and fleet or application software. This is a special-environment profile centered on mobility and inspection; the presence of humanoids broadens the portfolio but does not convert every product claim into a general-purpose autonomy result.

For X30, the official page lists IP67 protection, operation from −20 °C to 55 °C, a mass of about 56 kg, a rated payload of at least 20 kg, a laboratory maximum speed of at least 4 m/s, endurance of roughly 2.5 to 4 hours, and range of at least 10 km ^[9]. LYNX M20 materials distinguish effective payload, maximum load, unloaded and loaded endurance, laboratory maximum speed, and recommended speed. That vocabulary matters: maximum structural load is not useful mission payload, and an unloaded range is not the range with sensors, compute, lighting, and communications active.

Deep Robotics product brochures do not disclose company finance, and their performance specifications require their stated laboratory configuration and test conditions ^[12]. A separate issuer announcement reports a Series C financing of more than RMB 500 million in 2025 ^[13]. These sources answer different questions. Neither a brochure nor a financing announcement is independent evidence of long-run field reliability, revenue, margin, service burden, or mission return.

Commercial traction is primarily issuer-reported. Company materials describe product use across all 34 provincial-level regions in China, more than 44 countries or overseas regions, and hundreds of industry scenarios ^[8]. These counts show breadth claimed by the manufacturer, but “scenario” is not a standardized installed unit, active site, paid renewal, or successful mission. Public audited shipments, active fleet size, recurring software revenue, gross margin, and customer concentration were not found in the admitted sources.

Maturity is commercial industrial and specialized platforms with documented market availability and reported deployments. It is not independently verified sustained autonomy. A field reliability claim needs missions attempted, distance and hours, terrain distribution, weather, payload, communications, interventions, falls, recovery method, sensor cleaning, battery swaps, faults, and mean time to repair. IP67 helps define enclosure protection; it does not cover salt fog, chemical exposure, connector wear, mud adhesion, lens contamination, radio shadowing, or the safety of retrieval from a hazardous zone.

The developer ecosystem is visible but uneven by product. Official download and research pages offer manuals, hardware and software development documentation, GitHub links, and simulation support including Gazebo and Webots ^[10]. Public ROS and NVIDIA Isaac support were not sufficiently established in the captured official evidence, so both are unverified, while the documented development interfaces and simulation references are verified at the category level. Buyers should request exact firmware, API version, message timing, payload power, coordinate frames, safety-state access, and long-term compatibility.

Service support differentiates an industrial platform from a research purchase. Official purchase channels promise warranty and support and advise configuration matching for professional applications ^[11]. Publicly comparable service hours, regional spare inventories, response-time guarantees, loaner policy, battery replacement economics, preventive-maintenance intervals, and fleet uptime remain undisclosed. A buyer should test the service path during the pilot, including a deliberately injected fault and a replacement-part request.

The current organizer directory verifies Deep Robotics at booth C220. This establishes exhibitor identity and booth only, not program participation or product performance. Media-corpus visibility is unmeasured. Strengths are mature legged-product breadth, harsh-environment specifications, payload and developer options, and a visible industrial positioning. Limits are manufacturer-dominated deployment evidence, condition-sensitive specifications, incomplete public service economics, and no independent matched fleet reliability dataset.

Confidence is high for foundation year, Hangzhou location, product names, and published specifications as issuer claims; medium for geographic and scenario traction; and low to medium for sustained autonomy, mission reliability, fleet economics, and customer ROI. The X30 in the official field photograph below carries a bi-spectrum camera and acoustic imager. The rainy configuration is visible, but the image is not an independent test of ingress protection, consecutive mission completion, or autonomous inspection performance.

11.5 Deep Profile III — LimX Dynamics

The Korean rendering is 림엑스 다이내믹스, the English brand and company name are LimX Dynamics / LimX Dynamics Technology Co., Ltd., and the Chinese legal name is 深圳逐际动力科技有限公司. The current official history says LimX Dynamics was founded in Shenzhen in January 2022. Its disclosed headquarters address is in Nanshan I Valley, Shenzhen ^[14]. Because “incubated” is the exact public milestone, this chapter records 2022 as the foundation period without inventing a separate legal-incorporation date.

Flagships include the Luna humanoid, Oli humanoid, TRON 2 modular biped, TRON 1, and the COSA, VGM, DreamActor, and FluxVLA software or model stack. The portfolio spans research, developer training, general-purpose embodiment, and public commercial experiences. It should not automatically be called a household-consumer portfolio. Luna's launch positioning is closer to an interactive commercial and consumer-facing experience platform, while TRON and Oli also serve developers and researchers.

TRON 2 exposes a comparatively clear development surface: Python and C++, ROS 1 and ROS 2, high- and low-level SDK access, URDF models, and support material for Isaac Sim, MuJoCo, and Gazebo ^{[15] [16]}. Its optional arms and base configurations make it a modular embodiment rather than one fixed benchmark object. Public interface availability improves integration and reproducibility, but it does not disclose every controller parameter, training set, model weight, safety function, or warranty consequence of low-level access.

Luna's launch materials describe a 160 cm, 27-DoF body excluding end effectors, video-based motion learning, a no-code task editor, orchestration of as many as 200 synchronized units, about four hours of battery operation, external-power continuous operation, and a four-layer safety concept. The company announced a retail/preorder price of RMB 298,000 with a discount for an initial cohort ^[17]. These are dated issuer specifications and offer terms. They do not establish delivered-unit count, public-space incident rate, all-day autonomous task completion, audience retention, or lifecycle cost.

LimX announced a US$200 million Series B in February 2026 and a nearly US$200 million Pre-IPO round in July 2026 ^{[18] [19]}. The issuer describes US$400 million raised across the period and also reports thousands of orders, with more than half from global markets. The two announcements appear to describe distinct rounds, but no cap table, closing documents, audited cash receipt, order definition, cancellations, shipments, or revenue conversion were verified here. The amounts must therefore not be independently summed or used to infer valuation, cash on hand, or delivered scale.

Maturity is marketed developer platforms plus an emerging commercial-experience offering. TRON and Oli have public documentation that supports experimentation. Luna has launch, price, orchestration, and delivery claims, but sustained public-venue utilization and support economics remain unverified. The distinction is important: a developer platform can succeed through research sales and integrations, whereas a venue robot must generate repeatable audience or labor value every operating day.

SDK support is the strongest disclosed among the three profiles: Python/C++, ROS 1/2, simulator assets, and Isaac-oriented guides are publicly named. Openness remains partial. Interfaces and examples do not necessarily include production firmware, model training data, all policy weights, calibration pipelines, safety certification artifacts, or a complete fleet-orchestration backend. A buyer should map which components can run locally, which need vendor services, and which licenses allow modification and commercial deployment.

WRC 2026 status is verified by the organizer's exhibitor page, which lists LimX and named products including Oli and TRON 1 ^[20]. This verifies exhibitor presence and planned display, not performance or adoption. Media-corpus visibility is unmeasured, because no complete multilingual collection and exposure-normalized comparison was performed.

Service evidence includes public documentation, downloads, knowledge-base material, and supply terms, but response-time attainment, regional spare stock, repair turnaround, battery lifecycle, training hours, remote-monitoring scope, and software-support duration are undisclosed. For public venues, the buyer also needs content scheduling, fleet synchronization, operator permissions, privacy controls, emergency-stop staffing, offline behavior, safe power connection, storage, and a fallback show plan.

Strengths are a coherent embodiment-and-software roadmap, unusually visible developer interfaces, modular research products, and an explicit commercial-experience concept. Limits are issuer-only order and delivery claims, early evidence for sustained venue economics, incomplete disclosure of safety validation and fleet reliability, and ambiguity between developer, enterprise, and consumer market labels. Confidence is high for identity, 2022 incubation, Shenzhen location, named products, interface categories, financing announcements as announcements, and WRC listing; medium for commercial maturity; and low to medium for shipped scale, public-space reliability, recurring revenue, and ROI.

The official launch photograph below shows Luna's exterior, joints, and hand configuration. Its staged pose and lighting help identify the product, but do not verify unscripted task autonomy, safety in crowds, or all-day availability.

11.6 Same-Scale Profile Comparison

The profiles can be compared on disclosure, but not collapsed into a league table. MicroPort sells a regulated clinical system whose evidence attaches to device and indication. Deep Robotics sells mobility platforms whose value appears at the mission and fleet level. LimX spans developer hardware and consumer-facing commercial experiences whose value depends on integration, content, and operations.

11.7 Regulatory and Clinical Evidence: What Approval Does Not Say

Regulatory evidence begins with the legal device identity. Marketing names, generation labels, accessories, software versions, and intended uses can differ. A registry search should capture certificate number, applicant, model, classification, scope, issue and expiry dates, change history, and official labeling. Distributor pages and news releases are discovery aids, not substitutes for the regulator ^[5].

A Beijing government notice reports that Changmugu's ROPA6 obtained NMPA Class III registration across six orthopedic categories ^[6]. This is a useful example of breadth within a named regulatory system, not a fourth company profile. Registration supports legal and technical status for the specified products and uses. It does not by itself demonstrate superior accuracy, fewer complications, shorter procedures, better long-term outcomes, or economic advantage over manual or competing robotic methods.

Clinical evidence then asks what was measured and against what comparator. A single-arm case series can show feasibility and reveal complications, while a randomized or well-matched comparative study addresses relative benefit more directly. Surrogate endpoints such as placement error or console time may matter, but they should not silently stand in for patient outcomes. Learning curves, surgeon selection, case complexity, conversion, and follow-up loss can shift results.

Remote operation creates another evidence layer. Technical completion needs latency, jitter, outage, packet-loss recovery, video degradation, control authority, and fallback. Clinical governance needs credentialing, consent, local surgical capability, emergency conversion, device responsibility, data jurisdiction, and incident reporting. Teleoperation theory has long emphasized the stability and transparency tradeoff introduced by delay ^[23]. A network-success percentage cannot answer all of these clinical and organizational questions.

Post-market evidence matters because rare harms and maintenance interactions appear at scale. Hospitals should track procedure-specific utilization, abandoned robotic setup, conversion, equipment-related delay, adverse events, consumable failure, service interruption, and software version. Vendors should provide a field-safety and corrective-action route. Buyers must keep their own denominator rather than rely only on global cumulative milestones.

11.8 Field Reliability Is a Mission Probability

A specialized robot succeeds when it completes a useful mission and returns—or can be safely recovered—within an allowed time. The mission includes dispatch, transport to site, startup, localization, payload initialization, traversal, data capture, anomaly confirmation, communications events, battery management, return, charging, upload, and report handoff. A gait clip tests only a fragment.

Environmental qualification should be translated into a mission matrix. Temperature needs startup, sustained operation, thermal throttling, and battery effects. Ingress protection needs the exact configuration, connector covers, payloads, and maintenance after exposure. Slope and step values need surface material, friction, direction, approach, payload, speed, and repetitions. A wheeled-legged robot may be efficient on flat ground and step over obstacles, but transition reliability matters more than either best-case mode.

Communications loss is normal in metal structures, tunnels, and disaster zones. Define the timeout, stop behavior, local autonomy, route memory, geofence, reconnection, operator display, and recovery. A platform that freezes safely can still block a narrow passage. One that returns autonomously can encounter a changed environment. The fallback must be tested at the worst location, not beside the operator.

Serviceability changes total availability. Track mission aborts per hundred dispatches, operator interventions, falls, payload faults, battery swaps, software restarts, mean time to diagnose, mean time to repair, spare consumption, and technician travel. Separate robot-caused failure from site-caused cancellation, but report both for operational planning. Availability without scheduled-maintenance definition is ambiguous.

Manufacturer demonstrations remain useful for discovering capability and test ideas. Independent buyer tests should then recreate dust, wet surfaces, reflective corridors, stairs, cables, vegetation, low light, thermal load, full payload, network shadow, and a degraded battery. The purchase decision should be based on confidence intervals across consecutive missions, not the best run.

11.9 Service Support and Recurring Economics

Capital price is only the first invoice. Medical robots require instruments, sterile accessories, service, training, software support, room modifications, and backup capacity. Field robots require payload integration, batteries, chargers, communications, transport cases, spares, remote support, and possibly fleet software. Venue robots require content creation, staging, supervisors, storage, cleaning, connectivity, insurance, and seasonal refresh.

The business models therefore differ. A surgical vendor can earn from installed equipment and procedure-linked use, but hospital value depends on case volume, staffing, outcomes, capacity, and reimbursement. A field-robot vendor may sell hardware plus integration and support; buyer value depends on hazardous exposure avoided, inspection coverage, data quality, and outage reduction. An experience-robot vendor may combine hardware, software, content, and event service; value depends on utilization, repeat attendance, lead conversion, labor substitution, or brand objectives.

Recurring revenue is not automatically attractive to the buyer. It may align support and updates, or create lock-in. Contract review should list mandatory subscriptions, offline rights, API access, data export, software end-of-life, security patches, consumable exclusivity, battery replacement, training renewal, and termination assistance. A low hardware price can be expensive if utilization is low or proprietary consumables dominate.

Support must match consequence. A hospital needs case-aware escalation and a safe clinical contingency. A hazardous-site operator needs regional spares and a recovery plan. A venue may tolerate a short repair if a spare unit or non-robot show exists, but reputational incidents require immediate response. One global “24/7 support” phrase is insufficient; response, restoration, part availability, language, geography, and exclusions should be measurable.

11.10 Consumer-Facing Performance Is an Operations Problem

Public-facing robots are often evaluated as AI artifacts when they are closer to operated attractions or service systems. A synchronized performance may be precisely choreographed, which can be valuable. A no-code editor can reduce content-production labor. Neither demonstrates open-world autonomy. Buyers should label the mode: pre-scripted motion, operator-triggered sequence, supervised autonomy, remote teleoperation, or unsupervised behavior.

Safety includes speed and separation, stable footing, pinch and crush points, thermal surfaces, battery charging, cable management, emergency-stop access, crowd barriers, and restart authority. Collision research shows that injury risk depends on mass, velocity, geometry, compliance, body region, and contact condition rather than a single force number ^[24]. Public spaces add children, mobility aids, distracted visitors, photography, and intentional interference.

Privacy and trust are performance variables. Signs should disclose sensing and recording. Systems need data minimization, retention limits, access controls, deletion routes, and an offline mode where feasible. Spoken interaction should reveal limitations and handoff to staff. A network outage must produce a predictable safe state rather than confusing behavior.

The commercial denominator is useful operating time. Measure scheduled hours, available hours, audience interactions, completed sessions, supervisor interventions, resets, incident reports, content-change hours, and repeat use. For a venue, the counterfactual may be a screen, performer, static exhibit, or conventional service employee—not another humanoid. Novelty-adjusted value should be measured after the launch period.

11.11 Safety Authority and Human Responsibility

Human presence does not automatically make a system safe. Teleoperation can improve judgment while adding delay, limited perception, workload, and unclear responsibility. Supervision can catch failures, but an unreported expert intervention inflates autonomy. The evaluation should record every human action: setup, prompt, path approval, remote correction, object reset, fault clearance, and final confirmation.

Authority should be explicit. In surgery, the clinician commands the procedure while device, hospital, and team protocols bound use. In field inspection, an operator or mission manager dispatches, monitors, and decides recovery, while onboard controls own balance and immediate protection. In a venue, the floor supervisor owns crowd conditions and emergency stop, while content software sequences approved behavior.

Safe human-robot interaction research organizes hazards around separation, contact, predictability, and human factors ^[25]. The relevant control is not always an AI model. Physical guards, barriers, speed limits, compliant structures, validated stop circuits, checklists, staffing, and training often provide clearer assurance. Learning systems may improve perception or recovery, but certified or otherwise verified protection must not depend on an opaque confidence score alone.

Change management is part of safety. A software update, new payload, heavier end effector, different battery, new surgical instrument, changed room layout, or altered choreography can invalidate prior testing. Every deployed configuration needs a bill of materials, firmware and model versions, calibration, approved operating envelope, and rollback path.

11.12 Field Walkthrough: Substation Inspection from Procurement to Renewal

Consider a utility buying a legged robot for outdoor and indoor substation inspection. The objective is not “deploy AI,” but collect specified visual, thermal, acoustic, and meter data while reducing hazardous human exposure and preserving maintenance response.

Step 1 — Define the baseline. Record current inspection frequency, labor hours, exposure permits, missed readings, repeat visits, outage coordination, and incident history. Define which anomalies still require a person. This prevents a mobility demo from being mistaken for an end-to-end inspection result.

Step 2 — Freeze the configuration. Name the robot model, compute, cameras, thermal sensor, acoustic payload, lighting, radio, battery, charger, and software versions. Verify mass, center of gravity, payload power, weather sealing, and electromagnetic constraints. Published base-platform limits are not automatically valid after integration.

Step 3 — Map the route. Inventory surfaces, drainage grates, stairs, thresholds, vegetation, narrow aisles, reflective equipment, GPS denial, radio shadows, and restricted zones. Mark safe stops and human recovery access. The hardest segment should appear in acceptance testing.

Step 4 — Define mission outputs. Every asset needs identity, viewpoint, timestamp, sensor settings, acceptable image quality, anomaly rule, and report destination. Integrate with the maintenance system so a completed walk without usable data is counted as failure.

Step 5 — Test nominal missions. Run consecutive full-payload routes across day, night, dry, wet, hot, and cold conditions available during the pilot. Count dispatches, completions, missed assets, localization resets, teleoperation, falls, battery reserve, and reporting latency. Preserve video and logs for failures as well as successes.

Step 6 — Inject faults. Drop communications in the worst radio shadow, obscure one camera, simulate a low battery, close a planned corridor, and trigger a payload fault. Verify stop, local decision, operator alert, return, retrieval, and restart. Do not stage a fault the vendor already knows without also adding randomized repetitions.

Step 7 — Exercise service. Open a real support ticket, request a spare, restore from a software fault, and replace a wear item. Measure elapsed time and required skill. Confirm local language, remote-access controls, log ownership, cybersecurity practice, and escalation after hours.

Step 8 — Promote narrowly. Begin with one route and supervised operation. Expand only after mission completion, data quality, intervention, safety, and availability meet agreed thresholds. Keep manual inspection as a controlled fallback until seasonal and rare conditions are covered.

Step 9 — Review economics. Compare avoided exposure and labor with integration, supervision, batteries, communications, service, downtime, and residual manual work. Renewal should use active utilization and avoided cost, not installed-unit novelty.

The same discipline translates to manufacturing. For a medical system, the “line” is the perioperative workflow: scheduling, room setup, sterile preparation, docking, procedure, conversion contingency, reprocessing, maintenance, and outcome review. For a venue robot, it is content preparation, transport, setup, rehearsal, audience operation, charging, incident review, and teardown. The product earns value only when the whole workflow closes.

11.13 A Procurement Scorecard That Preserves Differences

Begin with identity and scope. Ask for legal seller, manufacturer, model, configuration, intended use, jurisdiction, software, accessory list, and evidence date. Reject an answer that mixes portfolio-wide and product-specific claims. Require every commercial count to define order, shipped unit, installed unit, active site, procedure, mission, or subscriber.

For medical robotics, request the official certificate and labeling, training and credentialing plan, clinical evidence table, post-market process, cybersecurity documentation, sterilization validation, service coverage, instrument economics, and case contingency. Ask the hospital's clinicians and biomedical engineers to own acceptance criteria rather than outsourcing the decision to a demo.

For specialized robotics, request environmental reports, full-payload mission logs, intervention definitions, fall and recovery data, communications behavior, battery lifecycle, payload interfaces, fleet monitoring, spare location, and service-level history. Repeat the buyer's route with randomized obstacles and an aging battery. Keep raw logs.

For consumer-facing systems, request safety architecture, crowd assumptions, privacy flow, content authoring, orchestration limits, offline mode, staffing, incident handling, battery and external-power rules, software term, and deletion/export rights. Run a full public-day rehearsal, not a five-minute stage sequence.

Confidence should be field-specific. A profile can have high confidence in legal identity and product specifications, medium confidence in deployment breadth, and low confidence in ROI. This is more honest than one company score. An undisclosed value is not zero, but it cannot support a procurement decision until supplied under diligence.

11.14 Limitations and Open Questions

This chapter relies heavily on current official company, public filing, regulator, organizer, standards, and research sources. Company product specifications and commercial milestones remain issuer claims unless explicitly identified otherwise. The analysis did not inspect confidential certificates, clinical study datasets, sales contracts, cap tables, service tickets, firmware, customer logs, or raw field trials.

The three profiles are deliberately heterogeneous. They reveal how evidence must change with consequence; they are not direct substitutes. MicroPort's disclosed revenue and installations benefit from public-company reporting that private companies do not provide. Deep Robotics' environmental specifications are not comparable with medical clinical endpoints. LimX's price and orchestration claims describe a different buying process from both.

Regulatory databases change, and approvals can be amended, renewed, suspended, or limited by labeling. Product names can cover variants. Financing announcements may precede closing and may use inconsistent currency conventions. Geographic counts can mean approvals, distributors, deliveries, or end users. All time-sensitive claims require renewal at procurement.

Independent long-duration evidence is scarce across field and public-experience robotics. Reliability tails appear after weather, wear, battery aging, staff turnover, and updates. Medical outcomes can depend on clinician experience and patient selection. Public venue value may decay as novelty declines. None is captured by a launch-day demonstration.

Open questions include how to publish failure denominators without exposing customers, how to verify remote surgical modes across networks and jurisdictions, how to standardize mission-level field benchmarks, how to insure autonomous systems in hazardous sites, how to support consumer-facing robots over a multi-year hardware life, and how safety cases should change when learned policies update.

Relation to Prior Surveys

Earlier chapters separated embodiment, manipulation, mobile orchestration, tactile interfaces, data systems, and VLA claims. This chapter tests those layers under three commercial regimes. General intelligence still matters, but its evidence is filtered through clinical authority, environmental exposure, service capacity, and the buyer's workflow. A robot becomes a product when those surrounding systems are measurable.

What to Learn Next

Chapter 12 turns from company profiles to synthesis. It will map the ecosystem across hardware, data, models, integrators, customers, standards, and capital, then ask where defensible value and unresolved bottlenecks sit. Carry forward four rules: preserve the unit of account, date every claim, separate issuer evidence from independent evidence, and evaluate the complete operating loop rather than the most visible machine.

References

1. MicroPort MedBot (2026a). About MicroPort MedBot. Official company history and address.
2. MicroPort MedBot (2026b). Toumai and Surgical Solutions. Official product source.
3. MicroPort MedBot (2026c). Financial Reports. Official investor-relations index.
4. MicroPort Scientific (2026). 2025 Annual Report. Public-company financial, order, installation, approval, and remote-use disclosures.
5. National Medical Products Administration (2026). Medical Device Data Search. Authoritative Chinese regulatory registry.
6. Beijing Municipal Government (2026). ROPA6 Class III Registration Notice. Government notice on six orthopedic categories.
7. Deep Robotics (2026a). Company Profile. Official identity, location, and portfolio source.
8. Deep Robotics (2026b). Company Milestones. Official foundation and development history.
9. Deep Robotics (2026c). X30 Product Page. Official environmental and performance specifications.
10. Deep Robotics (2026d). Downloads and Developer Resources. Official manuals and development links.
11. Deep Robotics (2026e). Where to Buy and Support. Official channel and service statements.
12. Deep Robotics (2025a). LYNX M20 Product Brochure. Issuer specifications and test-condition caveat.
13. Deep Robotics (2025b). Series C Financing Announcement. Issuer financing announcement.
14. LimX Dynamics (2026a). About LimX Dynamics. Official history, identity, and headquarters source.
15. LimX Dynamics (2026b). Developer Documents. Official SDK, simulator, and product documentation index.
16. LimX Dynamics (2026c). TRON 2 Specifications. Official product and interface specifications.
17. LimX Dynamics (2026d). Luna Launch. Issuer product, pricing, orchestration, battery, and safety claims.
18. LimX Dynamics (2026e). Series B Financing Announcement. Issuer announcement.
19. LimX Dynamics (2026f). Pre-IPO Financing Announcement. Issuer announcement.
20. World Robot Conference (2026). LimX Dynamics Exhibitor Page. Organizer listing and displayed products.
21. ISO (2010). ISO 12100:2010 — Safety of Machinery. Risk-assessment and risk-reduction principles.
22. ISO (2016). ISO/TS 15066:2016 — Collaborative Robot Safety. Application-specific collaborative-robot guidance.
23. Hokayem, P. F., and Spong, M. W. (2006). Bilateral Teleoperation: An Historical Survey. Delay, stability, and transparency context.
24. Haddadin, S. et al. (2008). Collision Detection and Reaction: A Contribution to Safe Physical Human-Robot Interaction. Physical interaction and collision context.
25. Lasota, P. A. et al. (2017). A Survey of Methods for Safe Human-Robot Interaction. Safety-method taxonomy.