Chapter 6: Industrial and Collaborative Arms — The Productivity Baseline

Overview

The question in this chapter is not “which robot arm is the most intelligent?” A more useful question is: How can a learned robot exceed the measurable productivity, precision, and safety of established industrial automation without losing that baseline? A trade-show system that grasps a previously unseen part once can be impressive. A factory system must handle the same part thousands of times within cycle time, stop safely in abnormal states, and produce a result the next shift can reproduce.

The thesis is that industrial robotics is not merely an older category for foundation-model robots to replace. Industrial arms, collaborative robots, three-dimensional vision, force control, safety PLCs, fixtures, tooling, and system integration form the production baseline that a learned robot must pass. A vision-language-action model may broaden task selection and generalization, but it does not inherit responsibility for repeatability, stable contact, stopping distance, protective stops, cycle time, or repair time. Moving from conventional automation to VLA is therefore an integration problem: uncertainty is granted bounded authority above verified control and safety layers.

Flexiv, ROKAE, and Mech-Mind Robotics are the three locked deep profiles for this chapter ^{[1] [4] [8]}. The selection is not an absolute ranking. Flexiv represents a force-sensing adaptive arm, ROKAE spans collaborative and conventional industrial arms, and Mech-Mind supplies the “eye and brain” layer that guides arms from multiple manufacturers. They occupy different roles in a cell, which makes evidence discipline more important than a single leaderboard.

After reading this chapter... - You can distinguish accuracy from repeatability and construct a manufacturing-cell error budget. - You can explain the roles of position control, hybrid position/force control, and impedance control in contact work. - You can compare Flexiv, ROKAE, and Mech-Mind across products, technology, finance and traction, maturity, developer ecosystem, corpus visibility, and WRC evidence. - You can distinguish a demonstration, pilot, customer acceptance, repeated deployment, shipment, and production capacity. - You can design a manufacturing pilot with safety standards, uptime, intervention, maintenance, and ROI in its acceptance record.

6.1 The Baseline Is a Closed Production Cell, Not an Arm

The strength of conventional automation is not simply that it has fewer degrees of freedom. It assigns ownership of uncertainty. Feeders and fixtures constrain part pose. The arm repeats taught trajectories. A process PLC manages interlocks. Safety equipment separates people from hazards. Inspection defines good and bad output, while a manufacturing system records production history. The arrangement can be inflexible, but the source of a failure is comparatively easy to trace.

A learned robot introduces a broader input distribution into this closed structure. A camera locates randomly piled parts, a model selects a task, and a policy corrects small deviations. Success then depends on more than model accuracy. Lighting, camera extrinsics, gripper wear, part tolerances, thermal drift, network latency, and scanner state contribute to the same result. Measurement and failure classification become more important as apparent generality increases.

Standardized robot performance testing, system-level safety integration, and classical force control remain the production baseline ^{[11] [12] [13] [14]}. ISO 9283 supplies test vocabulary for pose accuracy and repeatability. ISO 10218-2:2011 addresses the integrated system and cell rather than only a robot product. That edition has been superseded, so a live certification project must check the applicable jurisdiction and current edition. The classical control papers establish how a task frame can separate force- and position-controlled directions and how a desired dynamic relation between motion and force can shape contact.

The baseline is not one legacy robot specification. It is an operating contract combining accepted task success, defect rate, good units per hour, uninterrupted operation, safe response to hazards, and time to recover from failure. A model can improve some terms of that contract. It cannot erase the contract.

6.2 Accuracy, Repeatability, and Force Control Are Different Claims

Accuracy is the distance between a commanded pose and the pose actually reached. Repeatability describes how tightly repeated executions cluster under the same conditions. An arm can repeat consistently around a biased pose. Calibration can improve accuracy, yet load and temperature may bring the bias back. A catalog statement of “±0.03 mm” therefore does not mean that a complete process holds ±0.03 mm.

A cell error budget includes robot pose, base installation, TCP calibration, tool deflection, camera intrinsics and extrinsics, part-pose estimation, fixture tolerances, thermal effects, and contact deformation. The terms are not necessarily independent. An eye-in-hand camera makes extrinsic error depend on joint pose and cable stress. A long reach with a heavy tool changes structural deflection and can also change a force-sensor offset. A simple sum or root-sum-square estimate is only a starting approximation.

Force-sensing accuracy is also different from force-control accuracy. A sensor specification describes how well input is measured. Holding contact force near a target also depends on sensor placement, joint friction, control frequency, communication delay, environment stiffness, contact geometry, and filtering. A 0.1 N sensing figure does not establish 0.1 N polishing error on every surface.

Hybrid position/force control partitions a task frame so that, for example, force is controlled normal to a constrained surface while position advances tangentially ^[13]. Impedance control shapes the dynamic relationship between force and motion rather than commanding either alone ^[14]. The former needs a correct constraint frame. The latter realizes the desired behavior only within actuator, sensor, delay, and environment-stiffness limits. A learned policy may propose a contact target, but it does not remove those stability conditions.

Precision procurement begins by asking for the test method, model, payload, warm-up, pose set, speed, mounting, and statistical definition. Without them, extra decimal places create confidence without comparability.

6.3 Deep Profile I — Flexiv

The Korean rendering is 플렉시브, the English brand is Flexiv, and the Chinese brand is 非夕科技. The official history records establishment in 2016 and the start of adaptive-robot research and commercialization ^[1]. The official contact page lists operating entities in Shanghai and San Jose. This chapter records “founded in 2016, with Shanghai and San Jose operating centers.” The captured evidence does not establish that only one is the legal group headquarters.

The flagship portfolio includes the seven-axis Rizon 4 and Rizon 10, variants with an added force/torque sensor, the Moonlight parallel robot, and the Enlight full-sensing and MICO modular dual-arm products introduced in 2026 ^{[1] [2]}. Rizon is the central industrial platform here. The current product table gives all listed variants seven degrees of freedom and ±0.05 mm pose repeatability under ISO 9283, while the Rizon 4 group has a 4 kg payload and the Rizon 10 group has 10 kg.

Flexiv performance figures differ by Rizon variant, so the exact model must remain attached to every comparison ^[2]. The official table gives 0.1 N force-sensing accuracy for Rizon 4, 0.03 N for its external-F/T-sensor variant, and 0.2 N for the listed Rizon 10 variants. Reach and arm mass differ as well. These are issuer specifications, not a common independent benchmark. Applying the best 0.03 N figure to the whole product family would be inaccurate.

The technology position combines joint-level force sensing, torque-based control, seven-axis redundancy, and force and motion primitives. Seven axes can preserve a favorable contact posture and avoid obstacles. Redundancy also means there is more than one joint solution, so posture selection, singularity margin, cables, tooling, and collision constraints need active management. The identity is strongest in contact-rich processes such as polishing, precision insertion, and force-based inspection.

The developer surface is comparatively concrete. Flexiv describes its IDE and Robot Development Kit as providing C++ and Python, real-time state and control access, and higher-level task primitives. The current official RDK page lists both ROS 1 and ROS 2 packages, while the IDE page says every RDK installation includes the ROS 2 package ^{[1] [3]}. Procurement should still request the current operating-system, distribution, firmware, real-time-kernel, API-stability, and support matrix. Official NVIDIA Isaac Sim or Isaac Lab assets and a validated version matrix are unverified in the captured evidence.

Finance and traction are only partially disclosed. The official timeline records a Series B of more than US$100 million in 2020, a Series B+ of nearly US$100 million in 2022, and completion of a Series C with no amount in 2025 ^[1]. It also records production of the 100th adaptive robot in 2020. That milestone cannot be extrapolated into 2026 cumulative shipments or an active installed base. Revenue, profitability, current cumulative production and shipment, customer uptime, and renewal economics are undisclosed or unverified.

Maturity is best described as an industrial platform with commercial arms, controllers, developer tools, conformity marks, and a production history. Independent multi-shift uptime, mean time between failures, mean time to repair, spare-parts SLA, and process-level ROI remain unverified. CE and ETL evidence pertains to defined products and test scope, not automatic approval of every finished cell. An integrator adds tools, fixtures, workpieces, and new hazards and must validate the resulting system.

An official product photograph should show one Rizon variant together with its tool and contact surface. The photograph below appears in Flexiv's Rizon 4s launch section and shows a physical demonstration. One scene can explain morphology and the tool-workpiece relation; it cannot establish long-duration force tracking or production uptime.

6.4 Deep Profile II — ROKAE

The Korean rendering is 로케, the English brand is ROKAE, and the Chinese brand is 珞石机器人. The current official site and HKEX record identify ROKAE (Shandong) Robotics Group Inc. (珞石(山东)机器人集团股份有限公司), founded in 2015 with its headquarters and manufacturing base in Shandong ^[5]. Beijing is an R&D center or branch, not the current official headquarters label. The site claims annual capacity of 50,000 robots. Capacity is not actual annual production or shipment.

The product range spans xMate CR, SR, and ER collaborative robots; NB and XB industrial arms; intelligent welding systems; and mobile, bimanual, and humanoid lines ^[5]. This breadth can let one supplier address small collaborative work and heavier conventional cells. It also makes a blended “ROKAE robot” specification dangerous. Rated payload, reach, repeatability, mounting, protection, control version, and safety functions must remain tied to an exact model.

ROKAE lists ±0.03 mm repeatability and 0.5 N force-control accuracy for xMate ER3 ^[4]. These are issuer specifications. They are not directly comparable with another supplier until the test procedure and conditions are attached. Acceptance should request load, pose, speed, warm-up, and statistical treatment for repeatability, plus sensor location, surface stiffness, target force, filtering, and steady-state versus transient definition for force control. It must also clarify whether 0.5 N denotes sensing, steady tracking, or a maximum error.

The technical position includes proprietary xCore control, dynamics modeling, force control, collaborative functions, and broad industrial use. The official SR material describes hand guiding, a graphical interface, real-time secondary-development interfaces, Modbus, PROFINET, CC-Link, and offline simulation ^[6]. For an integrator, I/O behavior, fieldbus mapping, alarms, backup and restore, and controller replacement are more direct production assets than a broad AI label.

ROKAE's public documentation distinguishes an SDK, xCore manuals, plug-ins, ROS 2 packages, and RobotAssist ^[7]. The SDK supports external control through C++ and related interfaces, while the ROS 2 documentation exposes an xMate route. This verifies a developer surface, not identical feature and timing support across every robot family. Official ROS 1 support and NVIDIA Isaac Sim or Isaac Lab validation are unverified. A deployment needs a compatibility matrix across robot model, controller firmware, operating system, ROS distribution, and support lifetime.

For business traction, the current About page claims operations in more than 20 countries, more than 600 R&D patents and technical awards, annual production capacity of 50,000 robots, and more than 800 industry scenarios ^[5]. A separate dated official article's 40-plus-country and 40,000-plus cumulative-delivery claims must remain attached to that article rather than replace the current-page field. These are issuer-defined numbers, not audited active customers, installed robots, paid production cells, or annual shipments. An HKEX record verifies that 珞石(山东)机器人集团股份有限公司 listed under 3752 on July 9, 2026, at HK$38.00 per share, with 23,031,900 offer shares and HK$810.5 million estimated net proceeds before over-allotment. Revenue, profit, and shipment claims require the prospectus definitions and periods.

Maturity is assessed as a commercial supplier with collaborative and industrial product families, a factory, service structure, and developer documentation. Breadth and integration interfaces are strengths. The limits are the complexity of model and version comparison and the lack of public denominators converting scale claims into customer uptime or task economics. “Collaborative” in a model name does not by itself make an application safe. Sharp tooling, workpiece mass, fixtures, approach speed, and pinch points determine the finished-cell risk.

An official photograph should identify ER3 and its tool or place an industrial arm in an actual cell. The official application photograph below exposes the dense relationship among several xMate arms, tools, and fixtures. The image alone cannot resolve the exact models, safety functions, force-control error, or production performance.

6.5 Deep Profile III — Mech-Mind Robotics

The Korean rendering is 메크마인드 로보틱스, the English brand is Mech-Mind Robotics, and the Chinese brand is 梅卡曼德机器人. The company introduction reports a 2016 foundation and provides addresses in Beijing, Shanghai, and several international locations ^[8]. This chapter records “founded in 2016 and Beijing-based,” while keeping the holding-company and regional-entity map partially verified rather than asserting one fully resolved legal headquarters.

Mech-Mind is the important exception in this comparison. Its flagships are not a general industrial arm. They are Mech-Eye industrial 3D cameras and laser profilers, Mech-Vision machine-vision software, Mech-Viz robot programming and path planning, Mech-DLK deep learning, Mech-MSR inspection, and integrated Mech-Station products ^{[8] [9]}. It would therefore be wrong to fill payload or repeatability with a company-wide arm value. Those values belong to the third-party arm and tool selected for a cell and are recorded as “not applicable; verify per cell.”

The technical core joins 3D point-cloud generation, object recognition and pose estimation, grasp candidates, collision-aware planning, and robot communication in a deployable workflow. Random bin picking, depalletizing, machine tending, localization and assembly, and inline measurement are prominent applications. This layer can reduce fixture cost and handle a wider product mix. It does not automatically solve unobserved contact force, worn tools, residual failures on reflective, transparent, or dark surfaces, or the real-time servo behavior of a partner arm.

Mech-Mind reports more than 27,000 cameras installed across roughly 50 countries and regions ^[8]. The same issuer page reports more than 100 Fortune Global 500 clients and US$300 million in funding. This is not an audited count of deployed robot cells. One camera is not one complete cell or one active paid customer, cumulative installation is not the current operating population, and a country count does not reveal local SLA depth or spare-parts availability.

The developer ecosystem opens at a different boundary from an arm vendor's. The official download center provides Mech-Eye SDK packages, APIs, samples, and offline documentation for Windows, Ubuntu x86_64, and Ubuntu arm64 ^[10]. The product portal and documentation emphasize integration with multiple robot brands. Current official ROS package scope and official NVIDIA Isaac Sim or Isaac Lab assets and validation are unverified in the captured evidence. “An API exists” also does not mean real-time safety authority is exposed. Mech-Mind normally supplies pose or path outputs; final servo and safety authority remain with the arm controller and cell safety system.

Maturity must use a different physical denominator. A cumulative camera count and a broad software portfolio are meaningful issuer signals of commercialization and integration experience. They do not reveal customer-level success by part and lighting distribution, intervention-free time, engineering hours to integrate, repeat-purchase rate, or audited financial performance. ROI must be measured through the cell: labor reallocation, reduced fixtures, defect and rework changes, downtime, and model-retuning cost, not camera unit count.

An official product photograph is more useful when it shows the arm, gripper, bin, and surrounding cell rather than only a camera beauty shot. The official video cover below shows a physical deep-bin picking cell, although the camera sits outside the frame. It explains the application context of the eye-brain-hand stack but is not cycle-time or recovery evidence.

6.6 One Comparison Scale for Different Cell Roles

A simple arm ranking would misrepresent Mech-Mind and erase important model differences inside Flexiv and ROKAE. A better comparison asks which uncertainty each supplier is intended to own. Flexiv pushes contact and pose variation toward the arm and force-control layer. ROKAE spans collaborative through heavier industrial execution and integration. Mech-Mind reduces object and scene uncertainty through 3D perception and planning before sending a target to an arm.

The table does not select one universal winner. Precision insertion may prioritize contact sensing and stability. An automotive welding line may prioritize payload, supply chain, and service coverage. Random bin picking may be bottlenecked by perception, regrasp, and collision-free extraction. Selection should occur where the process's most expensive uncertainty meets the strongest applicable evidence.

6.7 Safety: Collaboration Is a Cell State, Not a Product Name

A collaborative robot is not synonymous with an unfenced robot. Human sharing can use safety-rated monitored stop, hand guiding, speed and separation monitoring, or power and force limiting. The finished application changes risk through the workpiece edge, tool, payload, approach direction, pinch geometry, and stopping time. A force-limited arm holding a sharp driver or hot component presents a different hazard.

The safety architecture must remain explainable without the learned model. A VLA may propose a goal or candidate action, but it should not bypass safety-PLC inputs or clear a protective stop. Independent layers should monitor allowed space, speed, force, tool state, and human access. A model timeout or network loss must lead to a defined safe state.

ISO 10218-2:2011 remains useful lineage for understanding integrator responsibility, but a current project must use the superseding edition, applicable national law, and relevant collaborative-application guidance ^[12]. A certification mark is input to a risk assessment, not its conclusion. Validation scenarios should cover emergency stop, protective stop, restart prevention, manual mode, energy isolation, residual pneumatic energy, network loss, blocked sensors, and dropped tools.

Collaborative operation can increase flexibility, but reducing barriers transfers engineering effort into validated sensing, stopping performance, and application analysis. The safety case becomes more detailed, not less necessary.

6.8 Uptime and ROI: Translating a Catalog into Production Economics

Uptime should not mean “the robot controller had power.” It should measure the portion of scheduled production time in which the cell could make accepted output. Planned stops, hardware faults, micro-stops, model restarts, camera recalibration, empty-bin waits, and human-approval delays should be separated so ownership is visible. One average can hide a healthy arm while perception retries consume the cycle.

Availability, performance, and quality in OEE are a useful start, but learned cells need additional denominators: out-of-distribution rejection, automatic-recovery rate, remote and on-site intervention minutes, success by model version, true and false safety stops, and calibration lifetime. A model update can improve grasp success while worsening cycle time or protective-stop frequency.

ROI includes more than labor reduction. Initial cost includes the arm, camera, gripper, controller, fixtures, safety equipment, integration engineering, data collection, tuning, and factory acceptance. Operating cost includes power, consumables, spares, service, labeling, retraining, cybersecurity, and lost output during downtime. Benefits can include redeployed labor, throughput, quality, lower rework, lower exposure to injury, changeover time, and floor-space savings.

Even a simple payback calculation needs conservative denominators. Annual net benefit should use actual added good output and verified labor reallocation, minus downtime and maintenance, rather than theoretical hourly throughput. Resident supplier engineers hidden inside a pilot must remain labor cost. Issuer-reported camera installations or plant capacity are not inputs to a buyer's ROI.

Procurement should ask for a raw event log, not only a dashboard screenshot. Timestamps must connect robot, vision, PLC, safety, and quality events. Otherwise each supplier can report a different clock and a failure becomes impossible to reconstruct.

6.9 From Deterministic Automation to VLA: Raise Authority in Steps

VLA research shows a path from vision and language toward action tokens and broader generalization. RT-1 demonstrates a closed-loop policy trained on a large real-robot dataset, while RT-2 co-fine-tunes web and robot knowledge ^{[15] [16]}. Their action rates and reported success belong to their experimental protocols. They do not establish industrial servo authority, certified safety, or any 2026 vendor deployment.

A practical adoption path is an authority ladder. First, a model structures a task description for human approval. Next, it selects one verified skill. Then it proposes bounded parameters or candidate poses. Only after these levels pass does it emit continuous action within a defined speed and workspace envelope. Independent collision checking, trajectory generation, controller limits, and safety remain beneath every level.

Code as Policies demonstrates an LLM composing explicit perception and control APIs ^[17]. The industrial lesson is not simply that code can be generated. API contracts bound what the program can do. A wrong coordinate from an API or one syntax error in a long program can still break execution. Static checks, sandboxing, timeouts, state assertions, and rollback are required.

There are verification layers between a candidate pose and hardware motion. TRAC-IK is a practical solver for joint-limited inverse kinematics, but it does not guarantee global completeness or collision avoidance ^[18]. TOPP-RA parameterizes time along a fixed path, while Ruckig generates jerk-constrained online trajectories ^{[19] [20]}. These tools turn waypoints into executable motion. They do not automatically make contact safe.

The ros_control lineage separates hardware interfaces from reusable controllers and makes resource ownership explicit ^[21]. When evaluating Flexiv or ROKAE SDK and ROS access, the important question is not only whether a message can be sent. It is who owns joint, torque, and I/O resources in each mode and how controller transitions are validated. Isaac support similarly requires more than a USD file: sensors, inertia, contact, actuators, and delay need validation against hardware.

A bounded learned layer can still create substantial value. It may select a known skill for a new SKU, choose among verified grasps, or route a low-confidence case to a person. The key is to preserve measurable fallbacks. If the model is unavailable, the cell should stop or return to an explicitly supported deterministic mode, not improvise through a silent behavior change.

6.10 Manufacturing Walkthrough — Random Bin to Precision Insertion

Consider a notional electronics process. Mixed metal housings arrive in a bin. A robot finds one, extracts it, and inserts it into a fixture in front of a machine. It then applies a controlled force to confirm seating, performs visual inspection, and places the accepted part in a tray. This cell makes the three profile roles comparable.

Step 1: Define process and hazards. Record part mass, sharp edges, pinch points, the machine door, and the operator's replenishment path. Define speed-and-separation or protective-stop conditions for human access. Validate emergency stop and energy isolation. The learned model has no authority to change these conditions.

Step 2: Build a conventional baseline. Automate one fixture-constrained part with taught points if possible. Measure repeatability at representative poses and loads, cycle time from bin pickup through insertion, tool change, and defect detection. Without this baseline, a learned system has no measured improvement target.

Step 3: Add perception variation. A layer such as Mech-Eye with vision and planning emits a point cloud, object pose, visibility, grasp candidates, and confidence. Construct tests combining reflection, dark surfaces, overlap, bin-wall proximity, vibration, and lighting. The success denominator should extend beyond detection to correct identity, pose, grasp, and collision-free extraction.

Step 4: Select arm and tool. If contact insertion is central, select an exact Flexiv Rizon variant or exact ROKAE xMate model with the real tool mass, reach, and force mode. Include cables and connectors in payload. Measure deflection at long reach and representative temperature. Selecting Mech-Mind does not remove the separate arm and safety contract.

Step 5: Calibrate frames and clocks. Version the base-to-arm, flange-to-TCP, camera-to-robot, and fixture-to-workpiece transforms. Record time synchronization and camera exposure. Use a reference object to measure both reprojection and physical TCP error. Exceeding a threshold should block production and request recalibration.

Step 6: Separate planning from execution. The vision system or VLA proposes an object and candidate action. A deterministic planner checks collision, joint limits, tool orientation, and extraction corridor. A trajectory layer applies velocity, acceleration, and jerk limits. The arm uses position control before contact and switches to a validated force or impedance mode during search and insertion.

Step 7: Judge force and quality. Do not infer insertion from final pose alone. Record peak force, force-displacement curve, seating depth, fastening state, and surface damage. Check sensor bias and tool wear by shift. Abnormal force should cause retract, re-observe, bounded retry, and then human intervention rather than an infinite retry loop.

Step 8: Test failure and recovery. Partially occlude a part, insert a wrong SKU, contaminate the camera, disconnect the network, and use a worn tool. Verify that the cell stops safely and classifies the cause. Route the first post-recovery part through enhanced inspection. Log automatic recovery separately from a human reset.

Step 9: Accept production. Across multiple material lots and shifts, record good units per hour, intervention-free time, false detection, near-collision, contact defects, MTTR, and safety stops. Treat resident supplier support as a separate labor cost. Freeze model, firmware, and SDK versions, and contract a regression-test scope for any change.

Step 10: Decide whether to scale. Passing one pilot does not justify immediate plant-wide replication. Verify that a second integrator and different operators can reproduce the result in a second cell. Update total cost with spares, remote support, security patches, and recalibration time after camera or arm replacement.

Manufacturing Cell Checkpoint

An example gate has five conditions. First, the cell meets both good-unit throughput and quality floor across stated part, lighting, and temperature ranges. Second, local and remote intervention time and causes stay below the limit during continuous operation. Third, the independent safety layer works in every hazard scenario regardless of model state. Fourth, the team recovers from camera, tool, and controller replacement within documented time. Fifth, a second integrator reproduces the same acceptance method.

The checkpoint turns “the robot completed insertion” into a production claim with a denominator. It also prevents a high-performing perception module from masking slow recovery, or a precise arm from masking poor object-pose estimates.

6.11 Evidence Ladder: Demo, Pilot, Production, and Shipment

A demonstration establishes physical possibility. A pilot establishes limited operation at a particular site. Customer acceptance establishes that agreed conditions were passed. Repeated deployment establishes some reproduction across cells or customers. Shipment establishes delivery, not active utilization, accepted output, or repeat purchase. Production capacity is weaker still as a deployment measure because it is the number that could be built, not the number actually built or shipped.

Supplier comparison needs the evidence type, date, unit, and denominator. “27,000+ installed” is Mech-Mind's cumulative camera unit claim. “50,000 per year” is ROKAE's stated production capacity. “The 100th robot” is Flexiv's 2020 production milestone. Putting all three numbers in one shipment column would create a false comparison even if each underlying sentence were quoted correctly.

Independent customer cases still need selection-bias questions. Were failed installations omitted? Did supplier engineers remain resident? Does price include integration? Are multiple cameras at one customer counted as multiple deployments? Was the accepted process still operating after a year? Missing values should stay disclosed as “undisclosed” or “unverified,” not be filled from market rumor.

Open ecosystem evidence also needs a ladder. A downloadable SDK is stronger than a marketing statement. Versioned documentation and examples are stronger than a download alone. A maintained ROS package, hardware-in-the-loop test, release policy, and support SLA are stronger still. “Supports ROS” says little without product, OS, distribution, message frequency, command mode, and safety boundary.

6.12 Limitations and Open Questions

This chapter relies primarily on official company sources plus captured primary research and standards. Company sources are useful for product scope and issuer disclosures, but they are not independent audits. Test apparatus, sample count, environment, customer contract, and accounting definition are often unavailable. Web pages can change under the same title, so procurement must freeze dated data sheets and contractual annexes.

Media-corpus visibility is unmeasured for all three profiles. There is no complete export of the defined eligible-article universe and deduplication rules, so this chapter does not manufacture article counts or share. The official WRC 2026 directory assigns A102 to the Zhejiang Humanoid Robot Innovation Center, so the Flexiv A102 lead must be discarded. ROKAE products are named within the shared B127 themed exhibition, which does not establish a standalone ROKAE A108 booth or program participation. No current official booth/program record was located for Flexiv or Mech-Mind. “Unverified” does not mean absent.

Flexiv's variant specifications, the ROKAE ER3 figures, and Mech-Mind's funding and installed-scale figures are issuer disclosures. They are not a common independent benchmark, and their units cannot be combined into one rank. In particular, Mech-Mind has no native arm repeatability or payload, so a cell must inherit those specifications from its partner arm and test the integrated result.

Three open questions remain. First, how quickly can learned-model updates move through safety validation and production change control? Second, how should uncertainty from vision, force, and a language-action model be calibrated into one task-level failure probability? Third, does a vendor SDK extend beyond research access to long-term support, cybersecurity, deterministic behavior, and rollback? If public evidence cannot answer them, they should become pilot contract tests.

The chapter also does not calculate a universal ROI. Labor rates, part mix, defect cost, uptime, support coverage, and depreciation vary by plant. A single payback number would imply precision that the evidence does not support. The method and KPI definitions are transferable; the economic inputs are local.

Relation to Prior Surveys

This chapter connects vendor mapping to supplier-independent foundations in kinematics, trajectories, control, and hardware abstraction. Inverse kinematics, time parameterization, jerk limits, force control, and the ROS control boundary remain applicable across products ^{[18] [19] [20] [21]}. Company finance, products, WRC status, and corpus visibility cannot be inferred from those principles and require separate official evidence.

What to Learn Next

Industrial arms are strongest in a fixed reference frame and a well-defined cell. Chapter 7 moves that baseline into factory aisles, warehouses, hospitals, and other shared spaces through AMRs and service robots. An arm may hold ±0.05 mm repeatability, yet the mission still fails if its mobile base docks poorly or cannot handle elevators, doors, people, traffic, and charging. The next chapter applies the same evidence ladder to localization, fleet orchestration, energy, human interaction, and service operations.

References

1. Flexiv (2026a). Flexiv Journey. Official company history.
2. Flexiv (2026b). Rizon. Official product specification.
3. Flexiv (2026c). Integrated Development Environment. Official developer documentation.
4. ROKAE (2026a). xMate ER and certificates. Official product specification.
5. ROKAE (2026b). About ROKAE. Official company profile.
6. ROKAE (2026c). xMate SR product sheet. Official product material.
7. ROKAE (2026d). Technical Docs and Developer Guide. Official SDK and ROS documentation.
8. Mech-Mind Robotics (2026a). Company Introduction. Official company profile.
9. Mech-Mind Robotics (2026b). Products and Solutions. Official product portal.
10. Mech-Mind Robotics (2026c). Download Center: Mech-Eye SDK. Official SDK download center.
11. ISO (1998). ISO 9283:1998 — Manipulating industrial robots: Performance criteria and related test methods.
12. ISO (2011). ISO 10218-2:2011 — Robot systems and integration.
13. Raibert, M. H., and Craig, J. J. (1981). Hybrid Position/Force Control of Manipulators.
14. Hogan, N. (1985). Impedance Control: An Approach to Manipulation, Part I—Theory.
15. Brohan, A. et al. (2023a). RT-1: Robotics Transformer for Real-World Control at Scale.
16. Brohan, A. et al. (2023b). RT-2: Vision-Language-Action Models Transfer Web Knowledge to Robotic Control.
17. Liang, J. et al. (2023). Code as Policies: Language Model Programs for Embodied Control.
18. Beeson, P., and Ames, B. (2015). TRAC-IK.
19. Pham, H., and Pham, Q.-C. (2018). A New Approach to Time-Optimal Path Parameterization Based on Reachability Analysis. IEEE Transactions on Robotics, 34(3), 645–659. arXiv:1707.07239.
20. Berscheid, L., and Kröger, T. (2021). Ruckig.
21. Chitta, S. et al. (2017). ros_control.
22. Taylor Howell et al. (2022). Predictive Sampling: Real-time Behaviour Synthesis with MuJoCo. arXiv:2212.00541.
23. Saran Tunyasuvunakool et al. (2020). dm_control: Software and Tasks for Continuous Control. DOI:10.1016/j.simpa.2020.100022.
24. Stephen Tian et al. (2019). Manipulation by Feel: Touch-Based Control with Deep Predictive Models. arXiv:1903.04128.
25. Xue Bin Peng et al. (2018). Dynamics Randomization for Sim-to-Real Transfer of Reinforcement Learning Policies. DOI:10.1109/icra.2018.8460528.
26. Xue Bin Peng et al. (2018). DeepMimic: Example-Guided Deep Reinforcement Learning of Physics-Based Character Skills. arXiv:1804.02717.
27. Tuomas Haarnoja et al. (2018). Soft Actor-Critic: Off-Policy Maximum Entropy Deep Reinforcement Learning with a Stochastic Actor. ICML 2018.
28. Wenzhen Yuan et al. (2017). GelSight: High-Resolution Robot Tactile Sensors for Estimating Geometry and Force. DOI:10.3390/s17122762.
29. John Schulman et al. (2017). Proximal Policy Optimization Algorithms. arXiv:1707.06347.
30. Ung-Hee Kim et al. (2017). A Novel Six-Axis Force/Torque Sensor for Robotic Applications. DOI:10.1109/tmech.2016.2640194.
31. Gianluca Palli et al. (2014). Development of an Optoelectronic 6-Axis Force/Torque Sensor for Robotic Applications. DOI:10.1016/j.sna.2014.09.023.
32. Alexandre Janot et al. (2014). Identification of Robot Dynamics with the Instrumental Variable Method. DOI:10.1109/tro.2014.2319567.
33. Manuel G. Catalano et al. (2014). Adaptive Synergies for the Design and Control of the Pisa/IIT SoftHand. DOI:10.1177/0278364913518998.
34. Kober, Jens et al. (2013). Reinforcement Learning in Robotics: A Survey. DOI:10.1177/0278364913495721.
35. Emanuel Todorov et al. (2012). MuJoCo: A Physics Engine for Model-Based Control. DOI:10.1109/iros.2012.6386109.
36. Christian Ott et al. (2008). Cartesian Impedance Control of Redundant and Flexible-Joint Robots. DOI:10.1109/robot.2008.4543616.
37. Stefano Chiaverini (1997). A Closed-Loop Inverse Kinematics Scheme for Constrained Redundant Manipulators. DOI:10.1109/70.585902.
38. Carlos Canudas de Wit et al. (1995). A New Model for Control of Systems with Friction. DOI:10.1109/9.376053.
39. Brian Armstrong-Hélouvry et al. (1994). A Survey of Models, Analysis Tools and Compensation Methods for the Control of Machines with Friction90209-7). DOI:10.1016/0005-1098(94)90209-7.
40. Oussama Khatib (1987). A Unified Approach for Motion and Force Control of Robot Manipulators: The Operational Space Formulation. DOI:10.1109/jra.1987.1087068.
41. Yoshihiko Nakamura et al. (1986). Singularity-Robust Inverse Kinematics. DOI:10.1115/1.3143764.
42. James E. Bobrow et al. (1985). Time-Optimal Control of Robotic Manipulators Along Specified Paths. DOI:10.1177/027836498500400303.