Open-Source HarmonyOS Bets on Robots: The Real Progress of EmbodiedAI 1.0.1

On June 5, at the Open-Source HarmonyOS Developer Conference, Liu Xiaofei, a provisional PMC committee member for Embodied AI, brought EmbodiedAI 1.0.1 to the stage. The version number marks a small step forward, but the content is anything but small: upgrades were made in four main areas—navigation planning, motion control, simulation development, and hardware adaptation. Three simulation environments—Native Emulator, MuJoCo, and Gazebo—were integrated at once, ROS compatibility retained, and adaptation verification completed for three types of bodies: humanoid robots, quadruped robot dogs, and commercial service robots. The source code was released that same day.

This move sends a bigger message than the version number suggests. Over the past few years, Open-Source HarmonyOS has been working towards the goal of a "full-scenario device OS"—from lightweight screenless devices, all the way to standard devices with screens—and now it has spun off embodied intelligence as its own separate track. Treating robots as an independent device category means it’s no longer just “HarmonyOS can run on robots,” but rather building a full toolchain and runtime environment specifically for robotic form factors.

What Exactly Did 1.0.1 Upgrade?

Let’s start with the technical foundation. The 1.0 stage of EmbodiedAI focused more on laying down basic capabilities. The emphasis in 1.0.1 is pushing each part further toward usability.

Navigation planning has addressed a long-standing pain point in open-source robot stacks: the handoff from global path planning to local obstacle avoidance often breaks. It might run perfectly in simulation, but once moved to real hardware, dynamic obstacles cause instability. In 1.0.1, planning capabilities have been reinforced, working together with the simulation workflow discussed below, making the performance of planning algorithms more predictable across different dynamics models.

Motion control upgrades are tied to different robot morphologies. Whole-Body Control (WBC) for humanoids, gait switching for quadruped robot dogs, and differential control for wheeled bases are vastly different paradigms. EmbodiedAI hasn’t taken the “build one universal controller” route; instead, it has abstracted control interfaces, allowing each morphology to plug in its own control backend. This is the right design—currently in embodied intelligence, there is no silver bullet, and doing proper interface abstraction is already half the battle.

Hardware adaptation is where HarmonyOS’s strengths start to show. It’s already an OS with a Hardware Driver Framework (HDF), meaning there are ready-made paradigms for drivers of sensors, motors, IMUs, etc. Compared to running ROS directly on Linux, where each vendor adapts drivers on their own, this offers architectural advantages.

Integrating Three Simulation Environments at Once—Worth Discussing

The simulation upgrades are the most notable part of 1.0.1. The version integrates Open-Source HarmonyOS Native Emulator, MuJoCo, and Gazebo.

These three serve very different purposes:

• MuJoCo is the de facto standard for physical simulation accuracy, excelling in contact dynamics and high-frequency control simulation. Reinforcement learning for robot policies almost always involves it.
• Gazebo is the long-time companion in the ROS ecosystem, strong in sensor simulation and scene construction, making it friendlier for multi-robot coordination and SLAM verification.
• Native Emulator is HarmonyOS’s own environment, tightly integrated with system calls, IPC, and application frameworks, simulating not just physical processes but also application-layer behavior.

Integrating all three may sound like “I want it all,” but on closer inspection, there’s logic. A typical developer workflow might go: train or fine-tune control strategies in MuJoCo, then perform full task-level scene validation in Gazebo, and finally run upper-level applications and system integration in the Native Emulator, before moving to real hardware. EmbodiedAI 1.0.1 connects this chain, meaning developers no longer have to manually juggle interfaces, align coordinate systems, or sync timestamps between the three tools.

This is more important than it appears. The biggest headaches for embodied intelligence developers aren’t weak single tools, but the sim-to-real gap and glue code between tools. Reducing friction here tangibly improves the ecosystem’s attractiveness.

Relationship with ROS: Compatible, Not a Replacement

HarmonyOS has taken a restrained approach here.

In the robotics world, ROS (especially ROS 2) plays a role similar to React in frontend development—not perfect, but the de facto standard, with migration costs so high that no one wants to switch. Any newcomer to this ecosystem must first say: I am compatible with ROS.

EmbodiedAI 1.0.1 maintains compatibility with ROS middleware, meaning developers’ existing ROS nodes, message definitions, and launch files can theoretically still run in the HarmonyOS environment. This is a pragmatic decision—if developers were required to abandon ROS for a completely new communication mechanism, no one would pay attention to this release.

But compatibility doesn’t mean having no cards of its own. The integration of the Native Emulator and system capabilities is something ROS simply cannot offer. Developers can choose: painlessly migrate pure ROS projects, or use deeper system capabilities for new projects. This “dual-track” strategy mirrors HarmonyOS’s approach to Android compatibility at the application layer—first win existing users through compatibility, then gain new ones with native features.

Three Types of Body Adaptation Complete—How Significant Is That?

The official announcement named three verified device types:

• Humanoid robots: high degrees of freedom, complex control, toughest realtime requirements
• Quadruped robot dogs: gait planning is core, outdoor dynamic scenes common
• Commercial service robots: typically wheeled base + robotic arm, high demands for long-term stability

These three basically cover the mainstream morphologies of current embodied intelligence. Getting them to run implies EmbodiedAI’s abstraction layer holds up across different dynamics and control paradigms. Of course, “completed adaptation and functional verification” is still far from “production-grade usability.” The 1.0.1 version number itself reflects the project’s own assessment—core capabilities are in place, but mass deployment is still a way off.

It’s worth comparing with two other industry benchmarks:

• NVIDIA Isaac takes the "GPU acceleration + high-precision simulation + large-model pretraining" route—high barrier, strong capability, but tied to NVIDIA hardware.
• ROS 2 + Nav2 + MoveIt is the standard open-source combo—flexible but severely fragmented, with each vendor redoing driver adaptation.

HarmonyOS sits somewhere between the two: offering OS integration and a unified toolchain beyond ROS 2, while being more open, lighter, and not tied to hardware like Isaac. This positioning makes sense—especially now that domestic robot manufacturers are multiplying and all need a base platform free from potential choke points.

18 SIGs—Organizational Strength Is Real

A less visible but equally critical fact: Open-Source HarmonyOS’s embodied intelligence track has already formed 18 dedicated SIG workgroups.

SIGs (Special Interest Groups) are small teams handling specific technical domains in open-source communities. The size of 18 is not small. For comparison, the Kubernetes community has about 20+ active SIGs supporting the world’s largest container orchestration project. This number suggests the project’s governance structure is serious—this is not just a few people writing code and slapping an open-source license on it.

But more SIGs also mean risks—coordination costs, interface alignment, version pacing—all require solid project management. How well this is handled will determine whether EmbodiedAI in a year’s time is a real ecosystem or just a “component grab bag.”

A Few Practical Questions for Developers

The release is good news, but for developers intending to actually use it, there are several questions to keep in mind:

First, documentation and example completeness. Upgraded core capabilities don’t guarantee a smooth onboarding experience—real development experience with 1.0.1 can only be judged after running the SDK.

Second, LLM/VLA model integration. Today’s embodied intelligence relies heavily on multimodal large models for high-level planning and semantic understanding. The release notes for EmbodiedAI 1.0.1 didn’t highlight model-layer integration plans, so developers will likely have to handle that themselves. If deploying closed-source models like GPT, Claude, or Gemini on robots for high-level reasoning, one can use aggregation APIs such as OpenAI Hub, which supports domestic direct access and OpenAI-format compatibility, avoiding the hassle of handling multi-vendor authentication—but running small models on endpoints still requires your own effort.

Third, real-hardware debugging workflow. Integrating three simulators is great, but the real difficulty in sim-to-real lies in details like domain randomization, sensor noise modeling, and control delay compensation. Simulation integration is just the first step.

Fourth, community response speed. Having 18 SIGs sounds lively, but response time to issues and pace of PR merges are the hard metrics for judging an open-source project’s health.

A Judgment

EmbodiedAI 1.0.1 is not a flashy release—no stunning demos, no performance benchmarks, and its launch was just a segment in a subforum of the Developer Conference. But this kind of “engineer-style” iteration is exactly what foundational software like a robot OS should be—embodied intelligence is deep water at every layer: hardware, control, perception, learning. Projects that try to tell the complete story in a couple of releases usually can't sustain it.

By opening an embodied intelligence track alongside its main terminal OS line, HarmonyOS shows it has already placed robots into its core future scenarios. This judgment faces little controversy—the notion of the humanoid robot mass-production era has been discussed for two years—but what’s truly worth watching is: when versions 1.1 and 1.2 come out, how many developers in the community will actually be using EmbodiedAI for projects, and whether third-party vendor adaptations can break through to dozens of models. These two numbers will tell more than any PPT.

The source code is already out—developers who are interested can pull a copy and give it a spin.

References

• Open-Source HarmonyOS Embodied Intelligence Release: EmbodiedAI 1.0.1 – IT Home: First-release coverage with core official info and event details