An open RISC-V solution for
embodied AI
From joint motors up to on-board intelligence, every layer can be swapped, every layer can be joined, and every layer has already been demonstrated on real hardware. What we publish is interfaces, inventories and reference implementations — not a closed robot.
Jointly released by the openKylin community, Milk-V, UltraRISC, Shanghai OpenLoong, SpacemiT and Kubuds Technology.
One robot, three time scales, one instruction set
The body needs a microsecond current loop, the cerebellum needs a millisecond control loop, the brain works at tens of milliseconds. All three sit on the same RISC-V ISA, so replacing any one layer does not force a rewrite of the other two.
Diagram drawn in-house as SVG; no third-party imagery. Use the labels on the left to jump to each layer.
The joint is the core of this layer
A humanoid robot has more than 14 rotary joints (shoulder, elbow, waist, hip); each joint is a motor, an encoder and a controller board. This layer is already RISC-V all the way through: joint drives, sensor I/O and wireless connectivity all have domestic RISC-V silicon to choose from.
RISC-V DSP-architecture driver that moves the FOC operators into hardware, aimed at joint motors.
400 MHz mixed-signal MCU, 4×16-bit ADC (2 MSPS), four motors from one chip; HPM6E8Y targets robot joints.
Shipped the first 32-bit general-purpose RISC-V MCU in 2019 (GD32VF103); paired with the GD30DR8306 motor-drive platform.
In-house Qingke RISC-V core; CH32V407 adds RVV vector extensions and dual 480 Mbps USB, CH32M030 is a motor-control MCU.
Self-developed RISC-V core with Wi-Fi + BLE — the robot's wireless link and cloud connection.
Provenance: figures marked “vendor data” come from public vendor material and were not independently re-measured by our team. Check the vendor's latest datasheet for exact part numbers and specifications.
The real-time and AI domains are physically separated
Motion control needs a millisecond loop while inference works at tens of milliseconds. The key design here is that the real-time cores and the AI cores live on the same die without stealing from each other — the real-time cores run RTOS and close the joint loops, the AI cores run Linux and handle perception and planning, and the two domains meet over rpmsg, shared memory and buses.
8× RISC-V 2.4 GHz, RVA23, IME; 2 dedicated real-time cores + 3 MB TCM; 10× CAN-FD and 4× GbE (EtherCAT / TSN).
8× RV64GCV (4×C920 + 4×C908), NPU 12 TOPS@INT8; full AGIROS + openEuler stack verified on hardware (visual robotic-arm grasping).
8× 2.0 GHz RV64GCBH, RVA22 compliant and RVA23-compatible (except V); Mini-ITX, PCIe Gen4 x16, 64 GB DDR4 ECC, UEFI + ACPI.
How to choose: deterministic work with a sub-millisecond period belongs on RTOS + MCU; trajectory planning and multimodal work belongs on Linux + AI cores. It is not either/or — it is a division of labour.
Inference stays local, data stays on the robot
Vision and environment data from homes and factories should not go to the cloud. This layer is assembled by compute tier: one RISC-V AI CPU can carry both real-time and inference, or an AI co-processor can sit next to the host SoC over PCIe / USB so compute upgrades independently.
60 TOPS (INT4 sparse peak, vendor data); AI and real-time domains run in parallel; local VAD / ASR / TTS / SLAM / VLA deployments verified.
Mixed-precision NPU 43.2 TOPS@INT4 / 10.8 TOPS@INT8; 8K ISP; board power under 8 W; CLIP / SAM / DINOv2 / Qwen2 / DeepSeek R1 adapted.
3× 64-bit RISC-V cores (two with 128-bit vector units); NPU 20 TOPS@INT8; 5 GB on-package DRAM at 1 TB/s; PCIe 2.1 / USB 3.0 to the host.
Provenance: “our measurement” figures were taken on a SpacemiT K3 board (Bianbu 4.0.7, kernel 6.18.3, collected 2026-10-21) with conditions stated next to every number. Vendor TOPS figures are peaks, not achievable throughput. Performance numbers are footnotes here, not the pitch.
One ISA, two system domains, three framework routes
The brain domain runs a Linux distribution, the cerebellum domain runs RT-Thread, and the two cooperate over rpmsg, shared memory and buses. All three framework routes already work; none of them is mandatory.
Dual domain: one SDK covers both domains; developers keep the open-source ecosystem they already know, with no lock-in to a single commercial system. The K3 real-time system and rpmsg examples are open source.
Five pluggable points — swap one, the other four stay
This is our testable definition of openness: replace any single point with another vendor's solution and the other four need no change, nor does the layer above.
Body: motors & I/O
Joint drives, MCUs, wireless modules. Swapping the controller only means swapping the BSP.
Options: Zhongke Benyuan / HPMicro / GigaDevice / WCH / EspressifCerebellum: real-time control
Real-time cores plus the RTOS control stack; the interface is the joint bus (CAN-FD / EtherCAT).
Options: K3 / A210 / UR-DP1000·TitanBrain: AI compute
NPU, AI CPU or co-processor, swapped by compute tier; the inference code above does not change.
Options: K3 / AX650N / RK1828Operating system
Linux distribution for the brain domain and an RTOS for the real-time domain, on one packaging standard.
Options: openKylin / Debian / Ubuntu / Fedora / openEulerAI framework & models
Pick FlagOS, llama.cpp, TileLang or a vendor runtime; models follow the framework.
Options: three community routes + vendor SDKsHow it gets verified: after swapping one point, the other four need no change and the layer above needs no re-adaptation, and the combination passes a conformance test. That is exactly what we are turning into specifications and a test suite next.
Six organisations, three commitments
The release name “Qiyuan” is a working codename. What we publish is interfaces and inventories, not a frozen product.
Fully open stack
Chip BSPs, system enablement, the AI software stack and robot sample code are all released openly.
Reference hardware
Reference boards and images based on K3 / A210 / Titan that you can reproduce and verify.
Open co-building
More silicon, robot makers and integrators are welcome to help complete the compatibility matrix.
Plug in at whichever layer suits you
Demonstrate one of the five pluggable points and the result belongs in the compatibility matrix; if you can offer a robot platform, let's write the reference implementation together.