资源限制是嵌入式ROS2从"能跑"到"跑得稳"之间那道坎。在STM32H7或树莓派Zero这类平台上，一个话题的默认配置就可能把内存吃光。优化不是炫技，是让节点在给定的硬件预算内完成实时任务。

资源类型与瓶颈识别

我在项目中踩过这个坑：一个激光雷达话题默认用SensorQoS（深度10），在只有256KB RAM的MCU上直接OOM。后来把深度降到4，加上静态消息池，才稳下来。定位瓶颈最快的方法是先看内存——嵌入式平台90%的"死机"都是内存先爆。

下面这张图帮你快速决策从哪个方向下手：

内存优化三板斧

嵌入式ROS2的内存优化，不是逐字节抠，而是从架构层面砍掉不必要的开销。三个最有效的手段：

• 静态消息池：预分配固定数量的消息缓冲区，发布/订阅时从池中取用，用完归还。避免运行时new/delete导致的内存碎片和不确定性延迟。micro-ROS的rclc库原生支持——调用rclc_executor_add_subscription_with_context时传入预分配的消息指针即可。
• 零拷贝订阅：在支持共享内存的DDS实现（如Cyclone DDS的iceoryx集成）中，订阅者直接读取发布者的缓冲区，省去一次拷贝。对激光雷达点云、图像这类大消息效果显著——实测在树莓派Zero上点云消息延迟从12ms降到3ms。
• QoS depth收缩：队列深度从10降到2，内存占用直接减少80%。绝大多数嵌入式场景下，depth=2已经足够——丢一帧远比内存溢出后整个节点重启划算。

CPU与执行器优化

ROS2的默认执行器（rclcpp::executors::SingleThreadedExecutor）把所有回调塞进一个线程，在嵌入式多核平台上白白浪费CPU。换成MultiThreadedExecutor并配以CallbackGroup，把高频率传感器回调与低频控制回调隔离到不同线程，CPU利用率能提升30%以上。

// 用CallbackGroup隔离高频与低频回调
  auto high_freq_group = node->create_callback_group(
    rclcpp::CallbackGroupType::MutuallyExclusive);
  auto low_freq_group = node->create_callback_group(
    rclcpp::CallbackGroupType::MutuallyExclusive);

  // 激光雷达回调（200Hz）走独立线程池
  rclcpp::SubscriptionOptions opts;
  opts.callback_group = high_freq_group;
  sub_lidar = node->create_subscription<sensor_msgs::msg::LaserScan>(
    "/scan", rclcpp::SensorQoS(),
    lidar_callback, opts);

  // 诊断信息回调（1Hz）走另一个线程池
  opts.callback_group = low_freq_group;
  sub_diag = node->create_subscription<diagnostic_msgs::msg::DiagnosticArray>(
    "/diagnostics", rclcpp::SystemDefaultsQoS(),
    diag_callback, opts);

  // 启动多线程执行器，指定线程数（典型值：2~4）
  rclcpp::executors::MultiThreadedExecutor executor(
    rclcpp::ExecutorOptions(), 2);
  executor.add_node(node);

实际开发中，大部分团队会把MultiThreadedExecutor的线程数设为CPU核心数减1，留一个核给系统调度。如果硬件只有单核（比如Cortex-M4），那就不要用多线程——单线程执行器配合rclc_executor_set_trigger的手动触发模式反而更可控。

带宽管理与QoS降级策略

带宽瓶颈在无线机器人场景尤其突出——Wi-Fi下实际可用带宽往往只有理论值的30%。降频是最直接的手段：激光雷达从20Hz降到5Hz，里程计从100Hz降到20Hz，对导航精度的影响微乎其微，但带宽占用降了75%。

如果降频后业务还是要求高数据率，就用消息压缩。ROS2原生不支持压缩，但可以在发布前用zstd或lz4压缩数据，话题类型改为CompressedPointCloud2这类自定义消息。我在一个农业机器人项目里用lz4压缩激光雷达数据，压缩比约3:1，解压耗时在Cortex-A53上只有0.8ms，完全可接受。

另一个容易被忽视的点：DDS发现协议在大型系统中会周期性广播参与者信息，占用不少带宽。把ROS_DISCOVERY_SERVER环境变量指向一个Discovery Server，把发现流量从广播改为单播，带宽能省掉一大截。

编译侧优化：从源头减重

嵌入式Flash不像PC那样随便塞几个GB。一个包含所有依赖的ROS2节点可能轻松超过2MB，而MCU的Flash通常只有512KB~2MB。两个编译选项能大幅减重：

• 静态链接（-static）：把动态库的依赖直接打进可执行文件，省去动态加载的元数据开销。代价是文件体积变大，但配合LTO反而可能更小。
• LTO（-flto）：链接时优化能跨编译单元内联函数、消除死代码。实测在ARM GCC上开启LTO后，一个包含激光雷达和里程计处理的节点，固件体积从1.8MB降到1.1MB，RAM占用也因死代码消除而减少约15%。

如果你用micro-ROS，还可以通过colcon的--cmake-args传入-DCMAKE_BUILD_TYPE=MinSizeRel，GCC会优先优化体积而非速度。在STM32H743上测试，这个选项让固件再缩减12%。