Fujitsu, FANUC, Yaskawa, Kawasaki and NVIDIA have not announced a finished joint robot or joint venture. The collaboration that began in July 2026 is exploring a sovereign, open control foundation for robots and equipment from different vendors, with potential businesses in manufacturing, logistics and healthcare. No product name, price or launch date is set; multi-vendor field trials and reproducible standards will determine its value.
The five companies agreed to explore a shared foundation—not ship a robot
Fujitsu's July 16, 2026 announcement says it began exploring Physical AI business opportunities with FANUC, Yaskawa Electric and Kawasaki Heavy Industries. Fujitsu will lead discussions on a collaborative control platform integrating NVIDIA's open Physical AI technologies to connect digital and physical operations.
The operative word in the release is “explore.” A joint direction does not mean a jointly produced humanoid, paying customer contract or international standard has been completed. Company-level terms, intellectual-property rights, products and support schedules need later documentation.
| Participant | Asset visible in the official announcement | Evidence still needed |
|---|---|---|
| Fujitsu | AI, computing, data and security; leads the control-platform discussion | Scope and versioning of Physical OS |
| FANUC | Industrial robots, AI capability and open-platform support for ROS 2 and Python | A customer trial connected to the common platform |
| Yaskawa | MOTOMAN NEXT, i3-Mechatronics and ROS 2 support | Responsibility boundary among robot, servo and higher-level AI |
| Kawasaki | Industrial robots, operating data and healthcare-integration experience | Safety and privacy validation in hospital workflows |
| NVIDIA | Cosmos, Omniverse, Isaac and Newton | Repeat performance and cost beyond tool adoption |
Fujitsu is proposing a common layer between business goals and robot control
A factory has production planning, safety PLCs, robot arms, AMRs and inspection equipment. A hospital separates prescription, specimen and reception systems from transport robots. Fujitsu's proposed foundation can be read as a layer that turns business-application goals into tasks for several robots and machines, then returns the results upstream.
The Physical OS layer described in Fujitsu's separate technology strategy belongs in that context. A spatial world model, task planner, vendor-specific control interfaces, and data and security policies need to connect. The current release describes direction; it does not finalize a public API, supported-equipment list, latency guarantee or price.
A common layer should not replace all real-time control inside equipment. Higher-level AI may request that a part move to the next process, while joint torque, emergency stops and safety zones remain under each vendor's certified controller. Without a documented right to reject conflicting commands, open integration can become a new single point of failure.
FANUC, Yaskawa and Kawasaki contribute different operating layers
FANUC emphasizes industrial robots and open-platform connectivity. Its executive statement in the release cites support for ROS 2 and Python and a plan to combine that with Fujitsu's autonomous AI platform. The test is whether flexible higher-level planning can be accepted without compromising established production-cell stability.
Yaskawa connects its i3-Mechatronics data-driven automation work, introduced in 2017, with MOTOMAN NEXT using NVIDIA GPU hardware as standard and support for ROS 2. Its role extends from robot arms into motion and servo data. Field trials must define the boundary between slower model decisions and millisecond control.
Kawasaki highlights industrial robots, operating data and healthcare applications. It discusses integrated hospital workflows from admission through diagnosis, treatment, surgery and recovery, but an environment mixing patients, specimens and medicines imposes tighter safety, liability and privacy conditions than ordinary logistics. A hospital demo is not the same as long-term clinical operation.
The NVIDIA stack supports training, simulation and robot development
The collaboration document names NVIDIA Cosmos world foundation models, Omniverse libraries, the Isaac open platform and the Newton physics engine. The intended roles are social and physical simulation for understanding or predicting real environments, physics-based virtual worlds and validation, and robot training, development and deployment.
The official NVIDIA robotics platform separates training, simulation and inference into distinct computing layers. Those tools may shorten development, but they do not show that a FANUC, Yaskawa or Kawasaki robot passed a customer task. Model and library versions, simulation conditions, hardware repetitions and human intervention are part of the evidence.
The Fujitsu Physical AI Technology Strategy places spatial world models and multi-robot collaboration on a long-term roadmap. A strategy document shows what the companies want to build; it is not a table of functions available for delivery today.
Manufacturing, logistics and healthcare stress the platform differently
Fujitsu identifies manufacturing, retail and logistics, and healthcare as initial fields. Examples include production planning that reacts to factory state, material movement informed by sales and inventory, and transport or reception tasks for medicines and specimens in hospitals.
The meaning of failure changes across them. A factory stop creates production loss; a logistics stop delays orders and congests fleets. A wrong medicine or specimen movement raises patient-safety and liability issues. Passing a common API test does not satisfy all operating requirements.
| Field | Systems to connect | Failure condition that must be tested |
|---|---|---|
| Manufacturing | Production planning, robot arms, inspection and safety PLC | An urgent plan change conflicts with safety control |
| Logistics | Sales, inventory, AMRs, doors and elevators | One fleet failure blocks robots from other vendors |
| Healthcare | Hospital operations, medicine and specimen transport, guidance | Patient misidentification, sensitive-data exposure or blocked emergency routes |
| Common layer | Models, interfaces, logs and updates | Signature failure, lost communication or a bad version deployment |
Open and sovereign control are compatible—but neither means unrestricted access
An open platform is intended to let participating companies and researchers use and extend common interfaces. It does not mean anyone may move a robot without limits. Authentication, role-based authorization, signed software, safety gates and audit logs are required.
Sovereign control is broader than keeping data inside Japan. It includes who can view production or patient data, reuse it for training, approve or refuse an update, and retain or delete incident logs. Locating a cloud domestically while leaving operating authority outside the customer does not complete data sovereignty.
The release itself notes that broader robot use increases exposure to cyberattacks, systemwide outages, malfunctions and confidential-data leakage. A multi-vendor platform simplifies connection, but one compromised account or update can propagate. Robot-group isolation, rollback and safe offline behavior have to be designed in.
Interoperability is proven in conformance tests, not a standards document
Fujitsu says it will pursue both standardization and openness for the collaborative control foundation. Even after a draft standard appears, interoperability remains unproven if robots from different vendors cannot perform the same workflow.
A strong trial places a FANUC arm, Yaskawa equipment, a Kawasaki system and another company's AMR on one site and asks them to share work reservations, maps, safety state and recovery. It should then update or stop one machine and verify that the others reroute safely. Conformance tests should intentionally inject latency, rejected commands, version mismatches and missing logs.
See Open-RMF multi-robot integration, the VDA 5050 3.0 guide and VIO versus SLAM for adjacent layers. Whether this alliance competes with or complements existing standards can be judged only after a concrete specification appears.
The alliance succeeds only when a shared customer site keeps running
The most valuable next update would be repeat work by robots from at least two manufacturers at one customer site. Success rate should be accompanied by intervention, fleet-congestion time, fault isolation, rollback and data-access logs.
The second requirement is business evidence: a paid pilot, customer, release schedule and support organization. The third is a standard deliverable—interfaces, security, data-sovereignty requirements and conformance procedures that an outside participant can reproduce.
Five prominent companies create a strong starting point. Long-term value depends on proving that robots of different generations and vendors can work together safely without forcing customers to surrender control of data or operations.
Frequently asked questions
Are the five companies launching a joint humanoid?
No. The official announcement covers exploration of Physical AI business opportunities and development of a collaborative control foundation. No joint humanoid model, price or launch date is set.
Does an open control platform let anyone command the robots?
No. Common interfaces still require authentication, role-based access, safety gates, signatures and audit logs. Openness and unlimited control are different concepts.
Does sovereign data mean only storing it inside Japan?
No. It also covers control over access, training reuse, update approval, log retention and deletion, and audit authority.
Official sources checked
- Fujitsu's official announcement of Japan Physical AI cooperation
- Fujitsu Physical AI Technology Strategy
- Official NVIDIA robotics platform
Last checked: August 23, 2026