Chapter 1: China's Robotics Industry — Scale and Structure

Overview

How large is China’s robotics industry? The question sounds straightforward, but any answer compressed into one number is likely to hide more than it reveals. Annual industrial-robot shipments, the cumulative installed base, mobile robots currently operating in facilities, humanoid prototypes, and robotics-company revenue count different things. The label “robotics” also covers businesses with different products and regulatory regimes: complete robots, critical components, controllers, tactile sensors, data infrastructure, and medical devices. The first step in reading scale is therefore not finding the largest number. It is fixing the denominator.

This chapter asks not “Where does China rank?” but “Which units and evidence make the structure of China’s robotics industry comparable?” Its thesis is that China should be read as a layered industrial ecosystem rather than a single market. Even at the hardware level, industrial arms, collaborative robots, autonomous mobile robots, quadrupeds, humanoids, surgical robots, dexterous hands, and tactile sensors address different buyers and validation processes. Control software, data, simulation, learned models, integration, and maintenance sit above and around that hardware. A company’s industrial value often lies less in one headline specification than in how reliably it connects these layers.

This perspective is particularly useful at WRC 2026. A moving body attracts attention on the show floor, but manufacturing buyers need different answers. Under what conditions was repeatability measured? How does the controller connect to plant equipment? Who restores the system after a fault? Can deployment data be reused in the next cell? Who owns the safety case for the integrated application? This chapter establishes the common ruler and evidence rules used to compare the 44 companies in the rest of the atlas.

After reading this chapter... - You will be able to distinguish market value, shipments, installed base, active deployments, and company revenue as different denominators. - You will be able to read China’s robotics ecosystem by layer, from industrial arms to touch, data, and medical robotics. - You will understand what standards, registries, issuer records, academic papers, product pages, and demonstrations can and cannot prove. - You will be able to explain why integration, safety, and operating metrics matter more than a stand-alone specification in a manufacturing cell. - You will be prepared to ask comparable questions at WRC and screen out unsupported scale claims.

1.1 Define “Robot” and “Scale” Before Counting

An industry map needs a unit of observation. A company selling one industrial arm and a company operating an entire warehouse fleet are both robotics companies, but their economics differ. For the arm supplier, equipment price, repeatability, payload, and lifecycle service may dominate. For the fleet provider, robot count is only one cost driver among warehouse-system integration, traffic control, charging, fault recovery, software subscriptions, and operations labor. Humanoid vendors currently span research systems, pilot deployments, and preparations for scale manufacturing. Medical-robot companies move through clinical and regulatory pathways as well as hospital procurement. One “sale” does not have the same economic meaning across these categories.

Common definitions and test conditions must be fixed before comparing robot precision, path behavior, speed, or payload. ISO 9283 defines performance characteristics and test methods for manipulating industrial robots, including pose accuracy and pose repeatability, but it does not set one universal threshold that every robot must exceed. The word “precision” on two data sheets is therefore not enough to rank two products. Pose, path, load, speed, temperature, calibration state, and the measurement procedure must be aligned ^[1].

The difference between accuracy and repeatability captures this chapter’s larger method. Accuracy asks how far the achieved pose lies from the commanded pose. Repeatability asks how tightly repeated outcomes cluster under the same command. A biased robot may repeat closely yet miss the requested point. Another may land near the target on average but vary too much for precision assembly. Market indicators behave similarly. A general impression of a “large market” matters less than what was counted, over which period, and whether the procedure can be repeated.

Market value, annual shipments, cumulative installed base, and currently active deployments are distinct denominators and cannot be substituted for one another. An enterprise registry is an authoritative starting point for legal identity and registration details, but it does not establish product performance or deliveries. The chapter packet also contains no harmonized 2026 series covering the entire China robotics market under one definition. We therefore do not combine figures from unmatched agencies or issuers into a synthetic ranking; every number must retain its object, period, geography, and source ^{[2] [1]}.

This limitation is a starting point, not an analytical failure. “Shipped” might mean units leaving a factory, units delivered to a distributor, or systems accepted by a final customer. “Installed” must separate trial installations from paid production deployments. “Active” could mean powered on once or meeting an uptime threshold over a defined period. “Customer count” may refer to contracts, parent companies, sites, cells, or robots. It is safer to design the columns of a comparison table before collecting numbers than to collect attractive numbers and invent the story afterward.

1.2 A Layered Industry, Not One Market

China’s robotics structure becomes clearer as a layered value chain than as a flat list of companies. At the base are motors, reducers, encoders, force-torque sensors, tactile sensors, batteries, and controllers. Above them sit arms, hands, mobile bases, quadruped and humanoid bodies, and surgical instruments. The next layer includes robot middleware, real-time control, coordinate frames, fleet management, teleoperation, simulation, training data, and models. At the top are integration and applications for welding, assembly, picking, transport, cleaning, hospitality, and surgery—the outcomes for which customers ultimately pay.

The layers are interdependent. A capable arm with an unsuitable gripper will fail at contact-rich work. Strong hardware under unstable communication or scheduling will exhibit timing variation. A large dataset with inconsistent coordinate frames and action definitions may resist reuse. A powerful learned model cannot assume the authority of a protective stop or an emergency stop. A useful company assessment therefore asks both “What does it make?” and “Up to which boundary does it accept responsibility?”

The table’s central lesson is that a useful number changes by layer. A component company may care more about design wins and long-term supply agreements than completed-robot shipments. A fleet-management provider may connect many manufacturers’ machines while selling few robots of its own. A medical robot may have lower unit volume than a general factory robot but face a higher barrier through approval, consumables, and hospital workflow. Conversely, an abundant prototype fleet does not by itself establish industrial scale if service coverage and component supply are not ready.

These layers also create different competitive moats. Component suppliers can accumulate manufacturing know-how and qualification history. Platform vendors can build distribution, service, and developer communities. Software providers can become embedded in a facility’s interfaces and operational data. Integrators accumulate application recipes and responsibility for commissioning. Application providers may capture recurring revenue, but they also inherit end-customer performance risk. “Vertical integration” is valuable only when the company can operate the joined layers, not merely list them on a website.

1.3 Keep the Evidence Hierarchy Separate from the Industry Hierarchy

A company atlas brings together different forms of evidence. Registry and regulatory records such as the National Enterprise Credit Information Publicity System are strong for legal identity and registration status ^[2]. Exchange filings and annual reports help establish financial and operating facts for a stated reporting period. Readers must separate the fiscal period covered by a report from the date on which the document was published. Even filings cannot be merged into a simple league table when issuers use different entity boundaries or metric definitions ^[11].

Official company sites are direct evidence of the portfolio and interfaces a vendor currently presents. SEER Robotics lists controllers, M4, RDS, and autonomous mobile robots through the same portal. That is useful evidence that the company addresses control and fleet layers in addition to individual vehicles ^[8]. PaXini presents tactile sensors, robot hands, humanoids, and the OmniSharing DB, indicating a proposed connection between contact hardware and data infrastructure ^[10]. A product list, however, does not automatically establish delivered volume, uptime, mean time between failures, or renewal revenue.

Academic work answers another class of question. The original ROS architecture separated robot-specific code from reusable communication and tooling ^[22]. Early ROS 2 work documented a redesign around distributed discovery and quality-of-service settings ^[19]. Yet using ROS 2 does not by itself make a control path deterministic. Response time across callback chains depends on executors, scheduling, the deployed kernel, and whether resource-reservation assumptions hold ^[16]. A company’s “open software ecosystem” should therefore be tested through measured latency, version policy, and recovery procedures as well as supported protocols.

For practical use, evidence can be separated into four tiers. First, standards, regulatory records, and filings lead for definitions and legal or financial facts. Second, peer-reviewed papers and public technical reports explain methods and conditional performance. Third, official product pages and data sheets are appropriate for offered scope and manufacturer claims. Fourth, demonstrations and news reports are valuable for discovery but weak for comparative conclusions. This is not a claim that lower-tier material is useless. The rule is to keep each item within the question it can answer.

Evidence also ages at different speeds. A historical standard can establish a durable distinction while its specific edition has been superseded. A paper may remain an important method reference while its software measurements no longer represent current releases. A product page may be current today and changed tomorrow. An annual report provides a stable period snapshot but necessarily lags operations. Recording retrieval date, reporting period, and version is therefore part of the claim, not clerical overhead.

1.4 The Historical Shift from Bodies to Systems and Data

The locus of robotics value can no longer be explained by the physical body alone. ROS introduced reusable processes, messages, packages, and record-and-replay tools that divided one robot’s functionality into software components ^[22]. The transform library then connected sensors and joints reporting in different coordinate frames and at different times. A connected transform tree can still contain wrong axes, units, or stale calibration, but treating frame contracts as first-class system objects was an important step ^[20].

Control was separated into layers as well. ros_control defined hardware interfaces, reusable controllers, read-update-write cycles, and resource claims ^[17]. This architecture enabled a robot arm from one vendor to participate in a broader software ecosystem, but a compatibility logo never guaranteed field performance. Executor and callback scheduling can affect control-relevant response time, and the bound depends on the deployed kernel and resource-reservation assumptions ^[16]. The same lesson applies when evaluating Chinese platforms: ask about hardware abstraction, time synchronization, logs, and supported version ranges, not merely whether an SDK exists.

The rise of data created a new comparison axis. RoboNet assembled action-conditioned video from seven robot platforms, totaling about 15 million frames, to study learning across heterogeneous systems ^[15]. Bridge Data collected 7,200 demonstrations over 71 tasks in 10 environments and examined how broad offline experience contributed to downstream imitation-learning generalization ^[14]. These numbers do not measure current commercial deployment. They show that where data is attached—to which embodiment, task, camera, and action space—became an independent variable in the robotics value chain.

The datasets’ limitations matter for industrial interpretation. Extensive use of a common embodiment limits what can be concluded about transfer to a different morphology. Changes in cameras and action spaces require platform-specific alignment. Results on short-horizon pushing cannot stand in for contact, safety, and recovery in a long assembly process. Data volume must be read with action semantics, sensor configuration, failure records, task horizon, and rights. A vendor selling a data platform should be asked for failed examples, cross-version compatibility, and deletion or retraining procedures as well as successful demonstrations.

Humanoid research illustrates the same layering. The latest inspected version of the survey spans more than 400 references and organizes locomotion, manipulation, planning, learning, whole-body tactile sensing, and foundation models as interacting research areas ^[13]. Its breadth is evidence that a humanoid is not merely an arm with more joints. It is not, however, evidence of any Chinese vendor’s 2026 manufacturing volume, revenue, or field uptime. Technical possibility and commercial evidence remain separate.

The historical path also explains why subsystem excellence does not automatically compose. A robust perception node, a repeatable arm, and a fast network can still fail together if timestamps, frames, ownership of state, or exception handling disagree. Industrial structure follows these interfaces. Some companies specialize at one layer; others attempt to own the connection between layers. The most credible integrated offering is not the one with the longest list of modules, but the one that can show interface contracts, acceptance tests, and support responsibility across the boundaries.

1.5 China’s Ecosystem Contains Multiple Commercialization Clocks

The ecosystem mapped in this book spans industrial arms, mobile-robot fleets, humanoid and quadruped platforms, tactile systems and data infrastructure, and medical robots. ESTUN represents industrial automation and robot arms and cites MIR for a 10.6% share of China sales in 2025. SEER Robotics presents controllers, fleet software, and autonomous mobile robots; Unitree presents a continuing family of legged platforms including H1, G1, and R1. PaXini extends from tactile sensors through hands and humanoids to a database. MicroPort MedBot published its 2025 annual report on April 30, 2026, illustrating a medical-robot business operating on a distinct regulatory and financial clock. The figure and dates establish only what the issuer records support, not superiority under a common cross-company denominator ^{[7] [8] [9] [10] [11]}.

This breadth makes it misleading to rank “Chinese robotics companies” as though they compete in one event. Industrial arms depend on process stability, integration partners, and service parts. Autonomous mobile robots depend on mapping, traffic control, warehouse interfaces, and charging operations. Humanoids face simultaneous bottlenecks in manufacturable hardware, behavior data, and a safe task envelope. Tactile companies must address durability, wiring, calibration, and connections from sensors to hands and learning data, not just sensor resolution. Medical robots are judged through clinical evidence, regulatory approval, hospital training, and consumables economics.

Quantitative claims in official material must remain inside the relevant clock. An issuer-cited sales share is useful when labeled with its analyst, year, geography, and sales definition. It cannot be expanded to all robot categories, cumulative installations, exports, or actual uptime. Until the denominator is matched with competitors, it is better treated as a hypothesis to verify than as an industry-wide declaration of superiority.

Portfolios nevertheless reveal intended expansion. SEER Robotics presenting controllers, fleet management, and mobile robots together suggests a path toward vertical integration. PaXini’s combination of touch sensors, hands, and a database suggests an attempt to extend a hardware sale into a data flywheel. Unitree’s sequence of product families suggests distinct research, price, and application layers. These are interpretations of offered scope. Customer-level availability, margin, and operating performance require additional records.

Geography matters, but the packet does not justify a city-by-city ranking. A legal registration address, an R&D office, a manufacturing site, a distributor, and a deployed customer site are different forms of presence. A regional “cluster” should therefore be decomposed into engineering talent, component supply, manufacturing capacity, system integrators, customers, capital, and public test infrastructure. Counting corporate names at an address would overstate some regions and miss cross-regional supply chains. Later company profiles preserve location as context without using it as a proxy for quality.

The different clocks also change what “commercial” means. For a mature arm, commercial readiness may mean repeat orders, service coverage, and verified cell throughput. For a mobile fleet, it may mean stable multi-robot operations and software renewal. For a humanoid, a paid developer unit or pilot is meaningful but not equivalent to production labor substitution. For a medical robot, a small number of approved and routinely used systems can be more consequential than many unregulated prototypes. A fair atlas does not force all of these milestones into one score.

1.6 Safety Belongs to the Integrated System

One of the most dangerous procurement errors is treating a robot body’s certificate or the word “collaborative” as a safety case for the entire cell. ISO 12100 describes an iterative process: determine machinery limits, identify hazards, estimate and evaluate risk, and reduce risk through inherently safe design, safeguards, and information for use ^[3]. The process prevents a successful demonstration from being mistaken for a safety argument. Predictable misuse, maintenance, tool changes, power loss, and restart matter alongside normal operation.

Safety belongs to the integrated robot system—including tools, workpieces, fixtures, sensors, control software, and worker routes—not only to the arm specification. Historically, ISO 10218-1 addressed requirements for the industrial robot, while ISO 10218-2 addressed robot systems and integration. The 2011 editions have been superseded by 2025 editions and must not be presented as the current compliance basis. ISO/TS 15066 is a 33-page technical specification for collaborative industrial robot systems and work environments that the official record says was reviewed and confirmed in 2022. The structural lesson is that manufacturer responsibility, integrator responsibility, and application risk assessment are not the same ^{[4] [5] [6] [3]}.

Collaborative robots are not an exception. The central lesson is that collaboration is an application property, not a brand attribute. Adding a sharp tool or moving a heavy workpiece quickly changes the hazard scenario even when the arm is unchanged. Collision research similarly shows that injury risk depends on the combined robot, tool, object, contact location, energy, and reaction strategy ^[21].

Safety methods can be organized into pre-collision prevention, measures during collision, and post-collision responses ^[18]. In a manufacturing cell, area monitoring and path planning, speed and force limits, collision detection and protective stops, emergency stops, and manual recovery form different defense layers. A learned model generating better actions is not a reason to remove those independent layers. Company comparisons should include the scope of safety functions, integration guidance, validation method, and access to stop and incident logs alongside speed and payload.

Safety is also an operating process. A validated cell can become unsafe after a tool change, payload change, layout update, firmware release, or new human route. Procurement should therefore define which changes trigger revalidation and who can authorize a restart. The answer may span the robot manufacturer, tool supplier, software provider, integrator, and factory owner. An impressive stop demonstration is useful, but the operational question is whether the same behavior is monitored, logged, maintained, and retested over the system lifecycle.

1.7 Worked Cell: Mixed-Container Transport Between Processes

Consider a concrete deployment: moving several types of parts containers between machining and inspection stations. Workers share the floor, container size and weight vary, and manual carts use some of the same aisles during parts of the day. A supplier proposes autonomous mobile robots, a top module, fleet-management software, and perhaps an arm. The show-floor demonstration will first reveal whether the robot avoids obstacles and reaches a marked destination. A purchase decision starts with the next questions.

First, write the task boundary. Define origins and destinations, allowed container dimensions, maximum mass, target throughput, shift length, charging windows, human crossing zones, and interfaces to lifts, automatic doors, and the manufacturing execution system. The payloads on PUDU’s product page can screen candidates, but they do not establish throughput on a particular facility’s slopes, floor joints, center-of-gravity conditions, top module, stopping-distance constraints, battery pattern, and network ^[12].

Second, draw the system boundary. Does the vehicle select destinations, does fleet management assign work, or does the factory system set priorities? When localization confidence falls or an aisle is blocked, decide which component replans and when control escalates to a person. If the system uses ROS-derived architecture, distinguish successful message delivery from completion within a control deadline. Quality-of-service settings do not eliminate executor scheduling and resource contention ^[16].

Third, design the acceptance test. Do not record only arrival success. Measure the 95th-percentile time from order receipt to delivery, travel time per human intervention, protective stops per shift, recovery time from blocked aisles, tasks missed because of charging, incorrect-container deliveries, and state consistency after network loss. If an arm is included, use ISO 9283 terminology to state the conditions for pose and path tests, while evaluating contact, perception, and process success separately ^[1].

Fourth, test exceptional states deliberately. Block a route, remove a map feature, delay an elevator response, interrupt the network, start with a partially charged battery, and present a shifted container. The goal is not to create a theatrical failure. It is to observe whether faults remain bounded, whether work state is duplicated or lost, and whether the operator receives enough information to recover. Run these tests at a safe scale before increasing fleet size. A ten-robot traffic problem is not merely ten copies of a one-robot problem.

Fifth, assign ownership. The robot manufacturer may own the body and embedded safety functions; a software provider may own fleet logic and interfaces; an integrator may own risk assessment and equipment connections; the factory may own work rules and maintenance data. Contracts should specify revalidation after updates, log retention, spare-parts lead time, on-site support response, and the procedure for reverting to manual operation. The resulting purchase is evaluated as reliable material-flow capacity, not as a count of robots.

A company product page establishes offered scope and issuer specifications; it does not establish audited market share or field uptime. Unitree’s chronology and product information support the existence of H1, G1, and R1 and 2025 activities but provide no audited shipment metric. PUDU’s T600 600 kg and T300 300 kg figures are nominal manufacturer payloads. Converting either source into installed base, failure rate, or shift throughput requires customer acceptance and operating records ^{[9] [12]}.

This walkthrough changes how a WRC visit should be planned. The most useful meeting is not always with the robot that performs the most dramatic motion. It may be with the controller team able to explain logs, the fleet team able to show recovery state, the integrator able to own cell acceptance, or the component supplier able to guarantee replacement. Show-floor observation becomes a structured prequalification exercise rather than a substitute for diligence.

1.8 Disagreements and Limits: Know What Not to Compare

The first disagreement concerns market boundaries. Results change depending on whether “industrial robots” include autonomous mobile and service robots, whether a humanoid is a research instrument or a commercial product, and whether medical-robot revenue includes equipment, services, and consumables. This book does not manufacture a harmonized 2026 total absent from the source packet. Later company figures retain the definitions of their primary records. Unmatched denominators may appear beside one another, but they are not added.

The second disagreement concerns performance context. A controller that succeeds in simulation can behave differently under real friction, sensor delay, cables, lighting, and human intervention. Early work on the “reality gap” proposed carefully modeled variation so a controller could not exploit simulator artifacts, but results on historical small robots cannot be transferred quantitatively to a modern manufacturing cell ^[23]. Deployment still needs staged validation with held-out real conditions and failures.

The third disagreement concerns technical possibility versus business durability. A humanoid review drawing on more than 400 references does not evaluate each company’s supply chain, service network, or balance sheet ^[13]. Conversely, a financial filing is strong evidence for stated issuer facts but says little about algorithmic generalization or cell safety. Compressing papers, product pages, filings, and customer operating data into one “confidence score” would erase where evidence is strong or absent. This atlas keeps them as separate columns and treats missing evidence as information.

The fourth limitation is time. Product pages change, and event demonstrations or developer models may differ from contractable production configurations. Historical records such as the 2011 ISO 10218 editions remain useful for understanding responsibility boundaries, but current compliance requires the applicable successor edition and jurisdiction. Every number and product scope in this chapter is tied to the stated source period. At WRC, readers should request current data sheets, deliverable configurations, and the terms under which claims will enter a contract.

The fifth limitation is access. A registry search may be authoritative yet interactive, a product site may omit archived revisions, and a customer may restrict operational logs. Absence of public evidence is not proof that a system fails. It is a reason to change the next step: request a primary document, arrange a controlled demonstration, add a contractual acceptance test, or leave the field unscored. “Unknown” is more useful than an invented estimate.

Relation to Prior Surveys

Terry’s reading note linked to the major humanoid survey provides a useful entry point to locomotion, manipulation, planning, and learning ^[13]. This atlas does not reproduce that technical landscape. It asks how Chinese companies occupy industrial layers and how their claims should be evidenced. Chapter 4 examines humanoid and quadruped platforms in detail; the purpose here is to establish that humanoids cannot be compared with industrial arms, fleets, tactile infrastructure, and medical robots under one denominator.

The earlier robotics lineage also offers a warning against equating software modularity with deployment maturity. ROS, coordinate-frame tooling, controller abstraction, real-time analysis, and cross-robot datasets each solved an important part of the system ^{[22] [20] [17] [16] [15]}. None alone confers end-to-end task success, safety, or commercial traction. That separation is carried forward into every company profile.

Manufacturing Cell Checkpoint

Before placing a Chinese robotics product into a cell, document five decision bundles.

1. Task schema: Specify parts, poses, tolerances, contact, cycle time, shift length, and allowed intervention. Do not stop at broad labels such as “picking” or “transport.”
2. Data and logging: Put commands, sensors, coordinate frames, software versions, stop reasons, and operator interventions on one time base. Do not collect only successful videos.
3. KPIs: In addition to average success, measure tail latency, time per intervention, time to first failure, recovery time, escaped defects, and throughput per shift.
4. Safety and recovery: Identify hazards including tools and workpieces; separate protective stop, emergency stop, manual recovery, and restart authority. Define revalidation after software change.
5. Ownership and contract: Assign boundaries among manufacturer, software provider, integrator, and factory operator. Put log access, spare parts, support response, and acceptance conditions into the contract.

Questions for a show-floor representative should follow the same structure. Do not stop with “How many have you sold?” Ask: “Over which period, for which model, and does the count mean shipped, installed, accepted, or actively operating?” Replace “What is the precision?” with “At which pose, load, speed, and test procedure was it measured?” Replace “Can it work with people?” with “Who owns risk assessment and validation for the cell including the tool and workpiece?” These questions reveal the distance between a compelling demonstration and a manufacturable system.

For an initial pilot, keep the decision reversible. Select a bounded task, retain a manual fallback, instrument failure and intervention, and define a stop condition before the first run. Expand only after the cell meets throughput and safety gates under real shift variation. A pilot is successful not when it produces an attractive video, but when it reduces uncertainty about technical fit, operations, ownership, and economics.

What to Learn Next

This chapter has established a common grammar: read China’s robotics industry as a layered ecosystem and attach a denominator and evidence tier to every number. Chapter 2, Selecting Leaders — Capital, Revenue, and Visibility, applies that grammar to the 44-company sample. It separates what funding, revenue, shipments and customers, product scope, and public visibility actually measure, then explains the division between 24 deep profiles and 20 atlas-only companies. Understanding the distinctions here is necessary to avoid treating fame, technical capability, and commercialization as synonyms.

References

1. International Organization for Standardization (1998). ISO 9283:1998 Manipulating industrial robots — Performance criteria and related test methods. ISO 9283:1998. [ISO, 1998]
2. State Administration for Market Regulation (2026). National Enterprise Credit Information Publicity System. Chinese government registry. [SAMR, 2026]
3. International Organization for Standardization (2010). ISO 12100:2010 Safety of machinery — General principles for design — Risk assessment and risk reduction. ISO 12100:2010. [ISO, 2010]
4. International Organization for Standardization (2011a). ISO 10218-1:2011 Robots and robotic devices — Safety requirements for industrial robots — Part 1: Robots. ISO 10218-1:2011. [ISO, 2011a]
5. International Organization for Standardization (2011b). ISO 10218-2:2011 Robots and robotic devices — Safety requirements for industrial robots — Part 2: Robot systems and integration. ISO 10218-2:2011. [ISO, 2011b]
6. International Organization for Standardization (2016). ISO/TS 15066:2016 Robots and robotic devices — Collaborative robots. ISO/TS 15066:2016. [ISO, 2016]
7. Estun Automation (2026). ESTUN profile. Official company website. [Estun Automation, 2026]
8. SEER Robotics (2026). SEER official portal. Official company website. [SEER Robotics, 2026]
9. Unitree Robotics (2026). Unitree company chronology. Official company website. [Unitree Robotics, 2026]
10. PaXini (2026). PaXini ecosystem. Official company website. [PaXini, 2026]
11. MicroPort MedBot (2026). MicroPort MedBot reports. Exchange filing and issuer reports. [MicroPort MedBot, 2026]
12. Pudu Robotics (2026). PUDU products. Official company website. [Pudu Robotics, 2026]
13. Gu, Z., et al. (2025). Humanoid Locomotion and Manipulation: Current Progress and Challenges in Control, Planning, and Learning. arXiv:2501.02116. [Gu et al., 2025] #73
14. Ebert, F., Yang, Y., Schmeckpeper, K., Bucher, B., Georgakis, G., Daniilidis, K., Finn, C., & Levine, S. (2022). Bridge Data: Boosting Generalization of Robotic Skills with Cross-Domain Datasets. Robotics: Science and Systems XVIII; DOI:10.15607/RSS.2022.XVIII.063; arXiv:2109.13396. [Ebert et al., 2022]
15. Dasari, S., et al. (2020). RoboNet: Large-Scale Multi-Robot Learning. CoRL; arXiv:1910.11215. [Dasari et al., 2020]
16. Casini, D., Blaß, T., Lütkebohle, I., & Brandenburg, B. (2019). Response-Time Analysis of ROS 2 Processing Chains under Reservation-Based Scheduling. ECRTS 2019. DOI: 10.4230/LIPIcs.ECRTS.2019.6. [Casini et al., 2019]
17. Chitta, S., et al. (2017). ros_control: A generic and simple control framework for ROS. Journal of Open Source Software. DOI: 10.21105/joss.00456. [Chitta et al., 2017]
18. Lasota, P. A., Fong, T., & Shah, J. A. (2017). A Survey of Methods for Safe Human-Robot Interaction. Foundations and Trends in Robotics. DOI: 10.1561/2300000052. [Lasota et al., 2017]
19. Maruyama, Y., Kato, S., & Azumi, T. (2016). Exploring the Performance of ROS2. Proceedings of the 13th ACM SIGBED International Conference on Embedded Software; DOI:10.1145/2968478.2968502. [Maruyama et al., 2016]
20. Foote, T. (2013). tf: The transform library. IEEE TePRA 2013. DOI: 10.1109/TePRA.2013.6556373. [Foote, 2013]
21. Haddadin, S. (2014). Towards Safe Robots: Approaching Asimov's 1st Law. Springer Tracts in Advanced Robotics, Vol. 90. [Haddadin, 2014]
22. Quigley, M., et al. (2009). ROS: an open-source Robot Operating System. ICRA Workshop on Open Source Software. [Quigley et al., 2009]
23. Jakobi, N., Husbands, P., & Harvey, I. (1995). Noise and the Reality Gap: The Use of Simulation in Evolutionary Robotics. In Advances in Artificial Life. [Jakobi et al., 1995]
24. Miomir Vukobratović et al. (2004). Zero-Moment Point — Thirty Five Years of Its Life. DOI:10.1142/s0219843604000083.
25. Kazuo Hirai et al. (1998). The Development of Honda Humanoid Robot. DOI:10.1109/robot.1998.677288.
26. Daniel E. Whitney (1969). Resolved Motion Rate Control of Manipulators and Human Prostheses. DOI:10.1109/tmms.1969.299896.