虚拟化+混合部署：让机器人开发同时拥有 AI 能力、Linux 生态与 RTOS 实时性

早期机器人开发的主流架构，日益凸显弊端

目前绝大多数机器人项目的硬件架构是这样的：

• 一块运行 Ubuntu 的主控板负责算法

• 一/多块 MCU（STM32 / ESP32 之类）MCU负责电机控制

两者通过串口、CAN 或 USB 连接。

这个方案走到今天有其合理性——Ubuntu 上可以跑完整的 ROS 2 生态，MCU 上裸机程序足够简单可控。但随着机器人算法复杂度不断提升，这套架构的工程代价开始集中显现：

多板卡，多工具链。 Ubuntu 侧用 colcon 编译 ROS 2 包，MCU 侧用 Keil 或 CubeIDE 烧录固件，两套环境各自维护，互不相通。出问题的时候，光是判断故障在哪一侧就要花不少时间。

串口 / CAN 透传是持续的瓶颈。 /cmd_vel 从 ROS 2 发出，经过协议转换，通过物理线缆到 MCU——中间任何一个环节引入延迟或丢包，调试链路极长。通信速率本身也是上限，在需要高频里程计或传感器回传的场景下，串口往往先成为瓶颈。

固件升级割裂。 Ubuntu 侧可以通过网络快速 OTA，MCU 每次改动都要重新烧录，远程升级需要额外开发一套机制。

硬件物料叠加。 主控板 + MCU 板 + 通信模块，多板卡意味着更高的 BOM 成本、更复杂的结构设计和更长的供应链。

这些问题在早期验证阶段不明显，但到产品化和批量交付阶段，会被成倍放大。

vmRT-Thread 虚拟化：在一颗 SoC 上运行多系统，物理隔离

我们基于 RK3588 平台（8 核心：4× Cortex-A76 + 4× Cortex-A55），使用 vmRT-Thread 虚拟化技术，在单颗 SoC 上同时部署了 Ubuntu 和 RT-Thread，两个系统之间实现硬件级别的资源隔离：

虚拟化层面的物理资源划分：

RT-Thread 域拥有固定的 CPU 核心、固定的内存地址段以及对应的硬件外设直通访问权限。Ubuntu 侧无论是 AI 推理把 CPU 跑满，还是内核模块崩溃，都无法越过虚拟化边界影响到 RT-Thread 的控制线程。

通信机制：虚拟网卡 + micro-ROS，对上层完全透明

两个域之间通过虚拟网卡互联，不需要物理串口或 CAN 总线。RT-Thread 侧运行 micro-ROS Client，Ubuntu 侧运行 micro-ROS Agent，双方通过标准 XRCE-DDS 协议通信。

Ubuntu 侧应用发布的标准 /cmd_vel 话题，经过 micro-ROS Agent 转发，在 RT-Thread 侧被 micro-ROS Client 接收并解析为电机控制指令。整个链路对 ROS 2 上层完全透明，不需要改变任何 ROS 2 应用代码。

通信/应用 调用链解析：三步完成配置

第一步：虚拟化环境部署

在 RK3588 开发板上部署 vmRT-Thread，创建两个 Guest 系统，按需为每个系统分配物理资源（CPU 核心、内存地址段、外设直通）。Ubuntu 域和 RT-Thread 域通过配置虚拟网卡建立通信链路。

第二步：RT-Thread 侧——硬实时控制

RT-Thread 域独占 PWM、编码器、Timer 等外设，实现以下功能：

• 电机驱动与 PID 闭环控制

• 麦克纳姆轮运动学解算（vx / vy / ωz → 各轮转速）

• 订阅 micro-ROS 话题，接收 /cmd_vel 速度目标

• 编码器采样与里程计发布

• 底盘急停响应

控制线程以固定周期运行，不依赖 Ubuntu 侧的调度状态。

第三步：Ubuntu 侧——智能感知与决策

Ubuntu 域完整保留 ROS 2 生态：

• ROS 2 Humble + Nav2 路径规划

• SLAM 建图（Gmapping / Cartographer）

• 激光雷达 / IMU 驱动接入

• micro-ROS Agent（桥接两域通信）

• 本地 AI 大模型推理服务（DeepSeek / Qwen 等）

对比传统方案具体改变了什么

1.  vs. Ubuntu + 裸机 MCU：

开发流程简化。RT-Thread 侧通过 env+vscode工具开发，系统镜像统一管理，不再需要维护独立的串口透传协议和 MCU 烧录流程。

调试链路变短。分层明确：传感器数据不通，查 Ubuntu 侧 ROS Topic；导航无速度输出，查 Nav2、TF、costmap；/cmd_vel 正常但车不动，查 micro-ROS Agent 连接状态和 RT-Thread 侧控制回调。问题归属清晰，不会在一个"大系统"里互相干扰。

硬件物料减少。省去独立 MCU 板、通信模块及对应电源和结构件，BOM 更简洁，整机体积更小。

2.  vs. Ubuntu + PREEMPT_RT：

底盘控制的实时性有了物理层面的保证，而不是依赖内核调度的"尽力而为"。Ubuntu 侧即使发生进程崩溃或内核异常，RT-Thread 域的控制线程和硬件外设仍然独立运行，机器人不会因为上层系统故障而失控。

扩展：接入本地大模型，构建完整的具身智能闭环

在上述架构基础上，Ubuntu 域可以进一步接入本地大模型推理服务（以 DeepSeek 为例），通过 MCP（Model Context Protocol）或 Function Calling 方式将自然语言指令转化为 ROS 2 控制动作。

用户输入自然语言指令后，大模型在本地完成意图解析和任务拆解，调用 MCP Server 暴露的标准工具接口（如 move_forward(distance)、rotate(angle)），生成对应的 ROS 2 话题或 Nav2 目标点，经过 Ubuntu 侧安全层仲裁后，速度指令通过 micro-ROS 进入 RT-Thread 执行。

分层职责清晰：大模型负责理解和规划，ROS 2 负责机器人语义与导航，RT-Thread 负责确定性执行，vmRT-Thread 虚拟化负责把不同实时性边界的任务在物理层面隔离开。

总结

vmRT-Thread 虚拟化混合部署的核心价值主要体现在两点：故障隔离和硬件虚拟化共享。

Ubuntu 域负责 ROS 2、AI 推理、SLAM/Nav2、可视化等复杂应用。RT-Thread 域保障底盘控制的实时性和确定性。  同时，虚拟化机制将 CPU、内存、中断、外设和虚拟网卡等资源在一颗 SoC 内按域分配、隔离或共享，让原本多板卡协同的系统收敛为双域架构。两域通过虚拟网卡 + micro-ROS 互联，对 ROS 2 上层应用保持透明。

后续我们会持续分享更多落地细节，包括：

• vmRT-Thread 核心分配与外设配置

• RT-Thread 侧 PID 控制与 micro-ROS 集成实现

• 本地大模型 + MCP 工具链搭建过程