ROS机器人实时性如何保障？

ROS 本身 不是一个实时系统，它的设计初衷是用于快速原型开发、算法研究和系统集成，而不是用于硬实时控制，ROS 的核心通信机制（如话题、服务、动作）都建立在标准操作系统之上，因此其性能和确定性受限于底层操作系统（通常是 Linux）的调度机制。

ROS 社区提供了多种解决方案，使得在 ROS 框架下实现实时性成为可能，这通常通过 “混合架构” 来实现：将实时性要求高的部分与非实时部分分离,并使用专门的实时内核或工具来处理前者。

为什么 ROS 默认不是实时的？

要理解这个问题，我们需要先了解 ROS 的工作方式和实时性的要求。

ROS 的非实时性根源

1. 标准 Linux 内核:

   • 抢占式不足: 标准的 Linux 内核是“通用”内核，为了公平性和吞吐量，其进程调度器是“公平调度”（CFS, Completely Fair Scheduler），它不能保证一个高优先级任务在严格的时间 deadline 前被执行，一个低优先级任务可能会长时间占用 CPU，导致高优先级任务“饥饿”或延迟。
   • 中断延迟不可预测: 当硬件（如传感器）产生中断时，标准 Linux 处理中断的时间是变化的，取决于当前系统状态,这种不可预测的中断延迟对于需要微秒级响应的实时系统是致命的。

2. ROS 通信机制:

   
   （图片来源网络，侵删）
   • 话题: 基于 TCP/UDP 套接字，数据需要从用户空间拷贝到内核空间，再通过网络协议栈发送,这个过程有延迟和抖动。
   • 服务: 基于 RPC（远程过程调用），通常也是通过 TCP 实现，其同步特性不适合高频、低延迟的交互。
   • 全局数据共享: 节点之间通过话题通信，而不是共享内存，虽然 ROS 2 引入了 DDS（数据分发服务），提供了更高效的通信,但仍然无法绕过操作系统的调度限制。

3. 节点调度:

   ROS 节点是普通的 Linux 进程，它们的执行顺序和优先级由 Linux 内核的调度器决定，而不是由 ROS 框架本身控制，一个计算密集型的 ROS 节点可能会阻塞整个系统。

实时性的关键指标

• 延迟: 从事件发生到系统响应的时间。
• 抖动: 延迟的变化程度，对于实时系统,低抖动和高确定性比低平均延迟更重要。
• Deadline: 系统必须在规定时间内完成的任务。

实现实时性的解决方案

为了克服上述限制，社区和厂商开发了多种技术方案，主要分为两大类：内核级方案 和 用户态方案。

内核级实时方案 (硬实时)

这是最彻底、性能最好的方案，通过替换或修改 Linux 内核来实现。

1. PREEMPT_RT Patch (实时补丁)

   • 是什么？ 这是 Linux 官方维护的一个内核补丁集，它通过将内核中大部分不可抢占的代码改为可抢占，并将大部分中断处理改为线程化中断，极大地增强了 Linux 的实时性。
   • 如何工作？
     • 内核抢占: 允许高优先级任务随时抢占低优先级任务,甚至是内核本身。
     • 线程化中断: 将硬件中断处理程序作为高优先级的内核线程来运行，而不是在不可抢占的上下文中运行,从而缩短了临界区的占用时间。
   • 优点:
     • 可以实现微秒级别的低延迟和低抖动。
     • 是一种“软实时”到“硬实时”的平滑过渡，与标准 Linux 兼容性较好。
   • 缺点:
     • 需要重新编译内核或使用预编译的实时内核镜像（如 Ubuntu PREEMPT_RT）。
     • 可能会引入一些性能开销,因为抢占和线程化中断会增加上下文切换的成本。
     • 并非所有硬件都完全支持。
   • 应用场景: 对实时性要求非常高的机器人，如高性能伺服控制、高频率传感器数据处理。

2. Xenomai / RTAI

   • 是什么？ 这些是独立的实时子系统，它们通过“双内核”架构工作，一个标准的 Linux 内核在“域”中运行，而一个独立的实时内核在另一个“域”中运行。
   • 如何工作？ 实时任务直接在 RTAI/Xenomai 内核上运行，与标准 Linux 内核完全隔离，它们通过一个称为“ Adeos”或“ Hypervisor”的层来共享硬件资源。
   • 优点:
     • 提供最强的实时性保证,通常是硬实时。
     • 与标准 Linux 内核隔离,互不影响。
   • 缺点:
     • 架构复杂,配置困难。
     • 与标准 Linux 的集成和兼容性不如 PREEMPT_RT。
     • 社区活跃度相对 PREEMPT_RT 较低。
   • 应用场景: 传统的工业自动化、航空航天等对可靠性要求极高的领域。

用户态实时方案 (软实时)

这类方案不修改内核,而是在用户空间实现实时逻辑。

1. ROS 2 的 DDS 实现与 CycloneDDS / Fast-RTPS

   • ROS 2 的进步: ROS 2 从设计上就比 ROS 1 更适合实时应用，它使用 DDS 作为中间件，而不是 ROS 1 的自定义实现。
   • DDS 的优势:
     • 高效数据分发: DDS 支持发布/订阅模式，数据直接在内存中传递，避免了多次拷贝，延迟远低于 ROS 1 的 TCP/UDP 通信。
     • QoS (Quality of Service): DDS 提供了丰富的 QoS 策略，可以精确控制数据传输的可靠性、优先级、 deadline 等，可以设置一个 DEADLINE QoS，如果发布者没有在指定时间内发送数据,订阅者会收到通知。
     • 内置发现和拓扑管理: 动态适应网络变化。
   • 实时性表现:
     • ROS 2 + DDS 可以实现低延迟、低抖动的通信，是一种软实时方案。
     • 它能保证通信层面的确定性，但无法保证一个计算复杂的 ROS 节点能在 deadline 前完成其回调函数，节点本身的执行仍然受标准 Linux 调度的影响。
   • 应用场景: 大多数需要高性能通信的机器人系统，如多机器人协作、自主导航，是目前 ROS 2 的主流方案。

2. 实时内核模块 / 用户态驱动

   • 是什么？ 将最关键的控制逻辑（如与硬件交互、PID 控制器）编写为一个内核模块或使用如 Xenomai 的用户态库 来运行。
   • 如何工作？ 这些任务直接在内核空间或用户态的实时环境中执行，绕过了标准 Linux 的调度延迟。
   • 优点: 可以实现非常精确的定时和硬件控制。
   • 缺点: 开发复杂，安全性要求高（内核模块崩溃会导致整个系统崩溃）,调试困难。
   • 应用场景: 电机控制板、传感器数据采集卡等硬件的底层驱动。

最佳实践：混合架构

在实践中，最常用和最推荐的方案是混合架构，结合 PREEMPT_RT 和 ROS 2。

架构示例：一个带有机械臂的移动机器人

1. 实时部分 (运行在 PREEMPT_RT 内核上):

   • 硬件接口节点: 一个独立的、高优先级的 ROS 节点（或直接是内核模块），负责以固定频率（1kHz）读取编码器数据、控制电机驱动器，这个节点使用 POSIX 或 C++11 的实时时钟和高精度定时器。
   • 控制算法节点: 另一个高优先级节点，运行在实时内核上，执行 PID 控制器或更高级的动力学控制算法，它以极高的确定性执行,确保机械臂的稳定和精确。

2. 非实时部分 (运行在标准 Linux 内核上):

   • 导航节点: 使用 move_base 等算法进行路径规划、避障，这些计算量大,但对实时性要求不高。
   • SLAM 节点: 运行 Cartographer 或 ORB-SLAM，构建地图,这是计算密集型任务。
   • 语音识别、视觉识别等高层 AI 任务。

3. 通信桥梁:

   • 实时部分和非实时部分通过 ROS 2 的话题进行通信。
   • 实时节点发布 /joint_states (关节状态) 和 /cmd_vel (速度命令)。
   • 非实时节点（如导航）发布 /move_base_simple/goal (目标点)。
   • 利用 ROS 2 的 QoS 策略，确保关键控制命令（如 /cmd_vel）使用最高优先级的传输设置,而地图等数据可以使用较低优先级。

这种架构的优势在于：

• 隔离: 实时任务被保护，不受非实时任务（如网络延迟、垃圾回收）的干扰。
• 开发便捷: 大部分非核心算法仍然可以在熟悉的 ROS 环境中开发和调试。
• 性能保证: 关键的控制环路得到了实时性的保证。

总结对比

最终建议：

• 如果你的机器人是消费级或研究原型，对实时性要求不高，直接使用标准 ROS 2 即可。
• 如果你的机器人需要稳定、可靠的控制，如移动机器人、机械臂，强烈推荐使用 PREEMPT_RT 内核 + ROS 2 的混合架构，这是目前业界最成熟、最平衡的解决方案。
• 如果你的机器人是工业级或安全关键型应用，需要最高级别的实时保证，则需要深入研究 Xenomai/RTAI 或采用专门的实时操作系统,但这通常意味着更高的开发成本和更小的社区支持。

标签： ROS实时性优化方案 ROS实时任务调度策略 ROS实时通信机制保障