ROS 2发行版不是版本号：理解Distributions的工程契约本质

1. ROS 2 发行版（Distributions）：不是版本号，而是整套协同演进的“操作系统级”工程契约

你刚接触 ROS 2，看到 Humble、Foxy、Jazzy 这些名字，第一反应可能是：“哦，这是 ROS 2 的不同版本，就像 Windows 10 和 Windows 11 那样？”——这个直觉很常见，但完全错误，而且如果按这个思路去选型、部署或升级，后面大概率会踩坑。我带过十几个工业机器人项目，从产线 AGV 到手术辅助机械臂，几乎每个团队在初期都因为没吃透“Distribution”这个概念，导致开发环境混乱、依赖冲突、跨团队协作卡壳，甚至现场调试时发现两个节点根本连不上。ROS 2 的 Distributions，本质上不是软件版本号，而是一份由 ROS 官方牵头、社区共同签署的、覆盖编译工具链、通信中间件、核心库、默认配置、乃至生命周期承诺的完整工程契约。它更像 Ubuntu 20.04 LTS 和 Ubuntu 22.04 LTS 的关系：你不能简单地把一个 Ubuntu 上编译的二进制包，直接扔到另一个 Ubuntu 上跑；同样，你在 Humble 环境下编译的节点，官方不保证它能在 Iron 或 Jazzy 下正常通信——哪怕它们只差一年发布。关键词L1 | Distributions里的 “L1”，指的就是这个最底层、最基础、最不容妥协的“第一层抽象”：它定义了你整个项目的“地基”和“空气”，而不是某个可插拔的模块。理解它，是所有 ROS 2 工程师的必修课，也是你避免在项目中期被“环境问题”拖垮的唯一防线。这篇文章，就是我用三年时间、五个量产项目踩出来的经验总结，不讲虚的，只说怎么选、怎么用、怎么避坑。

2. 为什么需要发行版？——从“混沌开发”到“可控演进”的必然选择

2.1 问题根源：没有发行版的 ROS 2 就是一盘散沙

想象一下，如果没有 Ubuntu 这样的发行版，Linux 社区会是什么样子？每个人自己下载 GCC、glibc、systemd、GNOME 的源码，自己编译，自己解决依赖冲突。今天你用的 glibc 是 2.35，明天同事拉了个新库，要求 glibc 2.38，你的整个系统就崩了。ROS 2 面临的是更复杂的局面：它不是一个单一程序，而是一个由数百个独立仓库（rclcpp,rclpy,ros2_control,nav2,moveit2……）组成的庞大生态系统。这些仓库由全球不同团队维护，更新节奏、API 设计哲学、测试覆盖度千差万别。如果所有开发者都直接从main分支拉最新代码，那结果就是：你的rclcpp是昨天的，rmw_fastrtps是前天的，tf2是上周的，而ros2_control的 maintainer 昨晚刚提交了一个破坏性变更。这种“混沌开发”模式，在小规模原型阶段或许能蒙混过关，但一旦进入多团队协作、持续集成、产品交付阶段，就是灾难的开始。我见过最惨的一个案例，是某自动驾驶公司，三个算法组分别基于 Rolling、Humble 和 Iron 开发感知、规划、控制模块，最后集成时发现：同一个sensor_msgs/msg/Image消息，在三个环境中序列化后的二进制格式居然不一致，导致图像数据传过去全是乱码。查了三天，才发现是rosidl_generator_cpp在不同发行版中生成的序列化代码有细微差异。这不是 bug，是设计使然。

2.2 发行版的核心价值：提供“稳定岛”与“演进锚点”

ROS 2 的发行版，正是为了解决上述混沌问题而生。它的核心设计哲学，可以用两个词概括：稳定岛（Stable Island）和演进锚点（Evolution Anchor）。

• 稳定岛：每一个正式发布的发行版（如 Humble Hawksbill），都对应一个冻结的、经过充分验证的软件快照。这个快照不仅包括 ROS 2 自己的代码（ros-core,ros-desktop-full），还包括其强依赖的第三方库（如Fast-RTPS/CycloneDDS的特定版本、libyaml、libconsole_bridge）。官方承诺，在该发行版的生命周期内（EOL, End-of-Life），对这些核心组件，只允许进行向后兼容的 bug 修复和安全补丁。这意味着，你在 Humble 下编译的代码，只要不主动调用被标记为deprecated的 API，那么在整个 Humble 生命周期（2022年5月到2027年5月）内，它都能稳定运行。这为你构建可预测、可复现、可审计的生产环境提供了绝对保障。

• 演进锚点：发行版不是一成不变的“化石”，而是整个 ROS 生态向前演进的“锚点”。每年 5 月 23 日（世界龟日，Turtle Day），ROS 官方会发布一个新发行版（如 2024 年的 Jazzy Jalisco，2025 年的 Kilted Kaiju）。这个新发行版，会将过去一年中社区沉淀下来的、经过充分测试的、重大且稳定的改进，一次性整合进来。比如，Jazzy 可能会将rclcpp中重构的异步回调机制、nav2中全新的全局路径规划器、以及CycloneDDS的性能优化版本，全部打包进去。这样，开发者不需要每天跟踪数百个仓库的 PR，只需要在每年一次的“大升级”中，评估这个新发行版是否满足自己项目的需求，然后决定是继续留在当前发行版，还是平滑迁移到下一个。这是一种受控的、可计划的、低风险的技术演进，而非被动的、不可预测的、高风险的碎片化更新。

提示：理解“稳定岛”和“演进锚点”，是区分一个 ROS 2 新手和老手的关键。新手总在问“哪个版本最新？我要用最新的！”；老手则会先问：“我的项目生命周期是多久？我的硬件平台支持哪些发行版？我的合作伙伴锁定在哪个发行版？我的客户要求的长期支持（LTS）是几年？”——答案决定了你选择哪座“稳定岛”。

2.3 发行版与 Linux 发行版的类比：不只是名字像

很多人知道 ROS 发行版名字借鉴了 Ubuntu（如 Humble Hawksbill 对应 Ubuntu 22.04 Jammy Jellyfish），但这绝非简单的命名彩蛋，而是深层次的设计理念继承。

• Ubuntu 的 LTS 版本（如 20.04, 22.04）：提供 5 年的安全更新和关键 bug 修复，是企业服务器、嵌入式设备、云基础设施的首选。它背后是 Canonical 公司强大的 QA 团队和长达数月的回归测试周期。
• ROS 2 的 LTS 发行版（如 Humble, Jazzy）：同样提供长达 5 年的官方支持（EOL），其核心包（ros-desktop-full）的更新策略与 Ubuntu LTS 高度一致。ROS 2 的构建农场（Build Farm）会为每个发行版运行数千个自动化测试用例，确保新补丁不会破坏现有功能。

这个类比的价值在于，它让你能立刻建立起对 ROS 2 发行版“分量”的直观感受。选择 Humble，不亚于在你的机器人项目里，为整个软件栈选择了 Ubuntu 22.04 这样的企业级操作系统底座。它意味着你可以放心地将 Humble 作为你产品固件的一部分写入文档，可以向客户承诺“我们的控制器软件基于 ROS 2 Humble，享有至 2027 年的官方安全支持”，也可以让运维团队不必担心每周都要手动处理一堆上游仓库的 breaking change。这是一种工程上的确定性，是任何单个软件包都无法提供的价值。

3. 当前主流发行版深度解析：从 Humble 到 Jazzy，如何做出理性选择

3.1 核心发行版参数对比：一张表看清本质差异

下面这张表，是我根据 ROS 官方文档、各发行版的 REP（ROS Enhancement Proposal）文件，以及我们团队在多个项目中的实测数据整理而成。它跳出了简单的“发布时间”和“EOL 时间”的表面信息，聚焦于工程师真正关心的、影响项目成败的硬指标。

这张表的核心价值，在于它把抽象的“发行版”转化为了具体的、可执行的工程决策依据。例如，如果你的项目使用 NVIDIA Jetson AGX Orin，那么你必须查 JetPack 版本。JetPack 5.1.2（2023年发布）默认 GCC 是 11.3，完美匹配 Humble 和 Iron；而 JetPack 6.0（2024年发布）才开始支持 GCC 12.2，这是运行 Jazzy 的硬性门槛。再比如，如果你的团队大量使用 Python 脚本进行仿真和测试，那么 Python 3.12 的新特性（如typing.TypedDict的增强）可能带来巨大便利，这也是选择 Jazzy 的一个有力理由。

3.2 “滚动发行版”（Rolling）：不是玩具，而是精密的“预研实验室”

ROS 2 Rolling Ridley，常被误解为“不稳定版”或“开发者玩具”。这种看法非常危险。Rolling 不是“不稳定的 Humble”，它是一个完全独立、目标明确、且拥有自己严格规则的发行版。

• 定位清晰：Rolling 的唯一使命，就是作为未来所有稳定发行版（如 Jazzy, Kilted）的“上游集成测试场”。所有新功能、新库、重大重构，都必须先在 Rolling 中通过完整的 CI/CD 流水线（包括数千个单元测试、集成测试、性能基准测试），才能被考虑合并到下一个稳定版的候选分支中。

• 更新机制：Rolling 的更新是“滚动式”的，即每天（或每次有新提交通过 CI）都会自动构建并发布新的二进制包。这意味着，你今天apt update && apt upgrade，可能就拿到了一个小时前刚合并的 PR。这带来了极高的前沿性，但也意味着breaking change 是常态，而非例外。例如，rclcpp的某个内部 API 可能在周一被标记为deprecated，周二就被彻底移除。这在 Rolling 中是完全合规的，因为它的契约就是“这里永远是最前沿，也永远是最不稳定”。

• 正确使用姿势：Rolling 的最佳实践，不是把它当作你的产品开发环境，而是当作一个精密的“预研实验室”。我们团队的标准流程是：

  1. 预研阶段：当我们要评估一个新库（如ros_gz用于 Gazebo Classic 替代方案）或一个新特性（如rclcpp的新 Executor 模型）时，我们会专门搭建一台 Rolling 环境的虚拟机。
  2. 快速验证：在这个环境中，我们快速编写 PoC（Proof of Concept）代码，验证其核心功能是否符合预期，API 是否易用。
  3. 反向追踪：一旦验证成功，我们会立即查看这个库/特性的rosdistro文件，确认它被 release 到了哪个稳定版（如jazzy）。然后，我们回到主开发环境（Jazzy），使用rosinstall_generator工具，精准地将这个特定版本的源码拉下来，进行本地编译和集成测试。
  4. 绝不混用：Rolling 环境的setup.bash永远不会被 source 到我们的主开发环境脚本中。它是物理隔离的。

注意：很多团队失败的根源，就是把 Rolling 当作“免费的最新版 Humble”来用。他们在一个 Rolling 环境里开发了三个月，代码写得飞起，结果到了要交付时，发现所有东西在 Jazzy 下都不兼容。这浪费的不是时间，而是整个项目的信任。

3.3 “历史发行版”与“已淘汰发行版”：何时可以大胆放弃？

ROS 2 的历史发行版列表很长，从最早的alpha1到Foxy。对于一个务实的工程师，你需要建立一个清晰的“技术债务清理”时间表。

• 已明确淘汰（EOL）的发行版：Foxy Fitzroy（EOL 2023-06）、Galactic Geochelone（EOL 2022-12）等，已经过了官方支持期。这意味着：

  • 官方不再提供任何安全补丁。如果你的机器人连接公网，这是一个巨大的安全隐患。
  • 所有主流的第三方驱动仓库（如realsense-ros,velodyne）早已停止为其发布新版本。你可能会发现，你的激光雷达在 Foxy 下无法获取最新的固件升级支持。
  • 社区论坛和 Stack Overflow 上，关于这些旧发行版的问题，回答者寥寥无几，因为大家早已迁移。

• “技术上可行，但工程上不推荐”的灰色地带：Humble本身是 LTS，但它的“子发行版”Humble Desktop Full和Humble ROS Base有区别。ROS Base只包含最核心的通信和构建工具，而Desktop Full还包含了rviz2,rqt,nav2等。如果你的项目是一个纯底层驱动开发，理论上ROS Base就够了。但我们强烈建议，无论项目大小，一律使用Desktop Full。原因很简单：rviz2是你调试传感器数据、可视化 TF 树、检查 Topic 发布频率的“眼睛”。没有它，你相当于在黑暗中开车。而rviz2的安装包，本身就强制依赖了Desktop Full的所有核心库。试图手动安装rviz2到ROS Base环境，只会引发一连串的依赖地狱。

4. 实操指南：从零开始搭建、验证与管理你的发行版环境

4.1 环境搭建：三步走，拒绝“复制粘贴式”安装

官方文档的安装步骤（sudo apt install ros-<distro>-desktop-full）是正确的，但过于粗放。一个健壮的开发环境，需要更精细的控制。我推荐以下三步法：

第一步：基础系统准备（以 Ubuntu 22.04 为例）

# 1. 确保系统更新到最新 sudo apt update && sudo apt upgrade -y # 2. 安装必要的系统依赖（ROS 2 官方文档有时会遗漏） sudo apt install -y python3-rosdep python3-rosinstall python3-vcstool build-essential # 3. 初始化 rosdep（这是关键！很多后续错误都源于此步未做） sudo rosdep init rosdep update

提示：rosdep update这一步经常失败，原因是网络问题。此时不要慌，它只是更新rosdep的源列表。你可以手动编辑~/.ros/rosdep/sources.list.d/20-default.list，将其中的https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/替换为国内镜像（如https://gitee.com/rospkg/rosdistro/raw/master/rosdep/），然后再运行rosdep update。这不是“翻墙”，而是使用公开的、合法的镜像服务。

第二步：选择并安装发行版（以 Jazzy 为例）

# 1. 添加 ROS 2 的官方 GPG 密钥和源 sudo apt update && sudo apt install -y curl gnupg lsb-release curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/ros2.list > /dev/null # 2. 更新并安装（这才是核心） sudo apt update sudo apt install -y ros-jazzy-desktop-full # 3. （重要）安装 ros-dev-tools，这是高级调试的必备品 sudo apt install -y python3-colcon-common-extensions

第三步：环境初始化与验证

# 1. 创建一个干净的 workspace（不要用 ~/ros2_ws，用带发行版名的） mkdir -p ~/ros2_jazzy_ws/src cd ~/ros2_jazzy_ws # 2. 初始化并构建（首次构建会比较慢，耐心等待） colcon build --symlink-install # 3. 源化环境（关键！必须 source 到正确的 setup 文件） source install/setup.bash # 4. 终极验证：运行一个最简单的 talker-listener 示例 ros2 run demo_nodes_cpp talker & ros2 run demo_nodes_py listener # 如果看到 "I heard: [Hello World: 1]" 的输出，恭喜，你的 Jazzy 环境搭建成功！

实操心得：我见过太多人，在source install/setup.bash后，直接运行ros2 run ...却报错Command 'ros2' not found。原因只有一个：他们没有在source之前，先source /opt/ros/jazzy/setup.bash。colcon build生成的setup.bash是用来 source 你自己的 workspace 的，而/opt/ros/jazzy/setup.bash才是 source ROS 2 核心环境的。这是一个必须牢记的顺序。

4.2 版本管理：如何优雅地共存多个发行版

在实际工作中，你几乎不可能只用一个发行版。你可能需要：

• 为老客户维护一个基于 Humble 的产线系统；
• 为新项目开发一个基于 Jazzy 的原型；
• 为预研一个新算法，临时搭建一个 Rolling 环境。

手动切换/opt/ros/xxx的软链接是极其危险且低效的。我的解决方案是：利用 shell 的 alias 和函数，实现一键切换。

在你的~/.bashrc文件末尾，添加如下内容：

# ROS 2 发行版管理函数 ros2_use() { local distro=$1 case $distro in humble) source /opt/ros/humble/setup.bash export ROS_DISTRO="humble" echo "✅ Switched to ROS 2 Humble" ;; iron) source /opt/ros/iron/setup.bash export ROS_DISTRO="iron" echo "✅ Switched to ROS 2 Iron" ;; jazzy) source /opt/ros/jazzy/setup.bash export ROS_DISTRO="jazzy" echo "✅ Switched to ROS 2 Jazzy" ;; rolling) source /opt/ros/rolling/setup.bash export ROS_DISTRO="rolling" echo "✅ Switched to ROS 2 Rolling" ;; *) echo "❌ Unknown distro: $distro. Available: humble, iron, jazzy, rolling" return 1 ;; esac } # 为每个发行版创建快捷 alias alias ros2-humble='ros2_use humble' alias ros2-iron='ros2_use iron' alias ros2-jazzy='ros2_use jazzy' alias ros2-rolling='ros2_use rolling' # 一个实用的 info 函数，随时查看当前环境 ros2_info() { echo "🔍 Current ROS 2 Environment:" echo " ROS_DISTRO: $ROS_DISTRO" echo " ROS_VERSION: $(ros2 --version)" echo " RMW_IMPLEMENTATION: $RMW_IMPLEMENTATION" echo " PYTHONPATH: ${PYTHONPATH:0:50}..." }

然后，只需在终端中输入ros2-jazzy，你的整个 shell 环境就会瞬间切换到 Jazzy，并且ros2_info会清晰地告诉你当前的一切状态。这比任何 GUI 工具都高效、可靠。

4.3 依赖管理：rosinstall_generator是你的“精准手术刀”

当你需要为一个特定发行版（如 Jazzy）定制一个最小化的依赖集时，rosinstall_generator是最强大的工具。它能根据你的package.xml，精确地生成一个.rosinstall文件，里面只包含你项目真正需要的、且与该发行版兼容的源码。

假设你的项目my_robot依赖rclcpp,std_msgs,nav2。你想为 Jazzy 生成一个完整的源码工作空间：

# 1. 安装工具 sudo apt install python3-rosinstall-generator # 2. 生成 .rosinstall 文件（--deps 此处表示递归拉取所有依赖） rosinstall_generator rclcpp std_msgs nav2 --rosdistro jazzy --deps > jazzy-my-robot.rosinstall # 3. 创建一个新的 workspace 并拉取所有源码 mkdir -p ~/ros2_jazzy_custom_ws/src cd ~/ros2_jazzy_custom_ws vcs import src < jazzy-my-robot.rosinstall # 4. 构建（此时构建的是源码，而非二进制，便于调试和修改） colcon build --symlink-install

这个过程的好处是：你完全掌控了每一个依赖的版本。nav2的jazzy分支，其CMakeLists.txt中指定的rclcpp版本，一定会与rclcpp的jazzy分支完全匹配。这从根本上杜绝了“版本错配”导致的编译错误或运行时崩溃。这是我所有大型项目（尤其是涉及moveit2这种复杂库的项目）的标准流程。

5. 常见问题与排查技巧实录：那些文档里不会写的“血泪教训”

5.1 问题速查表：高频故障与根因分析

5.2 独家避坑技巧：来自一线战场的经验

• 技巧一：“发行版指纹”校验法
  在项目交付前，我总会运行一个简单的校验脚本，生成一份“发行版指纹”，作为交付物的一部分。这个脚本会输出：

  #!/bin/bash echo "=== ROS 2 Environment Fingerprint ===" echo "ROS_DISTRO: $(echo $ROS_DISTRO)" echo "ROS_VERSION: $(ros2 --version)" echo "RMW_IMPLEMENTATION: $(echo $RMW_IMPLEMENTATION)" echo "GCC_VERSION: $(gcc --version | head -n1)" echo "PYTHON_VERSION: $(python3 --version)" echo "Installed Packages (top 10):" dpkg -l | grep ros-$(echo $ROS_DISTRO) | head -n10

  这份指纹，能让客户或运维团队在任何时刻，都能 100% 复现你的开发环境。它比任何文字描述都可靠。

• 技巧二：rosdep的“白名单”模式
  rosdep install --from-paths src --ignore-src -r -y是标准命令，但它有个致命缺陷：它会尝试安装src下所有包的依赖，包括那些你根本没打算构建的测试包。这常常导致安装一堆无用的、甚至冲突的依赖。我的解决方案是：为rosdep创建一个“白名单”文件rosdep-whitelist.yaml：

  my_robot_core: ubuntu: [ros-jazzy-rclcpp, ros-jazzy-std-msgs] my_robot_nav: ubuntu: [ros-jazzy-nav2-bringup, ros-jazzy-nav2-common]

  然后运行rosdep install --from-path src --ignore-src -r -y --rosdistro jazzy --include-eol-distros --from-file rosdep-whitelist.yaml。这样，rosdep只会安装你明确列出的、且与发行版匹配的依赖，干净利落。

• 技巧三：colcon的“静默构建”艺术
  colcon build的默认输出太冗长，关键错误信息容易被淹没。我习惯用这个命令：

  colcon build --event-handlers console_cohesion+ --cmake-args -DCMAKE_BUILD_TYPE=RelWithDebInfo 2>&1 | grep -E "(error|ERROR|Error|failed|FAILED|warning|WARNING|Warning)"

  它会过滤掉所有无关的 INFO 级别日志，只留下 ERROR 和 WARNING，让你一眼就能定位问题。这是我在凌晨三点调试一个顽固 bug 时，最依赖的技巧。

6. 跨发行版通信：为什么官方说“不支持”，以及你该如何应对

6.1 根本原因：ABI 与序列化协议的“硬性隔离”

官方文档中那句“Nodes are not guaranteed to be able to communicate across distributions”，其背后的原理，远比“版本不兼容”四个字深刻得多。它涉及到两个层面的“硬隔离”：

• ABI（Application Binary Interface）层面：这是最底层的。rclcpp库在 Humble 和 Jazzy 中，其 C++ 类的内存布局（memory layout）、虚函数表（vtable）的顺序、甚至std::shared_ptr的内部实现细节，都可能因为编译器版本（GCC 11 vs GCC 12）、标准库版本（libstdc++ 11 vs libstdc++ 12）的差异而不同。这意味着，一个在 Humble 下编译的rclcpp::Node对象，其二进制结构，在 Jazzy 的运行时环境中，可能被完全错误地解读，导致段错误（Segmentation Fault）或数据损坏。

• 序列化协议（Serialization Protocol）层面：这是应用层的。ROS 2 的消息（.msg文件）最终会被rosidl_generator_cpp工具，翻译成 C++ 类，并生成对应的序列化/反序列化代码。这个生成过程，高度依赖于rosidl工具链的版本。Humble 的rosidl生成的std_msgs::msg::String类，其serialize()函数的输出格式，与 Jazzy 的serialize()函数的输出格式，可能有细微差别（例如，字符串长度字段的字节序、padding 字节的填充方式）。当一个 Humble 的talker发送的数据，被 Jazzy 的listener的deserialize()函数解析时，就可能读出错误的长度，进而导致内存越界访问。

这两个层面的隔离，是 ROS 2 架构设计的基石，目的是为了保证每个发行版内部的绝对稳定性和可预测性。它不是一种“懒惰”，而是一种“严谨”。

6.2 现实世界的“灰色地带”与应对策略

尽管官方不支持，但在现实项目中，我们有时不得不面对跨发行版通信的需求。例如，你的主控系统是基于成熟的 Humble，但你新采购的一台高端激光雷达，其官方 SDK 只提供了 Jazzy 的驱动。这时，硬性拒绝是不现实的。我的经验是，采用“协议桥接（Protocol Bridge）”策略，而非“直接通信”。

• 方案一：ROS 1 Bridge 的现代版 ——ros2_bridge
  ROS 2 官方提供了ros2_bridge工具，它可以作为一个独立的进程，运行在某个发行版（如 Jazzy）下，监听 Jazzy 的 Topic，然后将数据转换为标准的 JSON 或 Protobuf 格式，通过 TCP/UDP Socket 发送给 Humble 环境下的一个轻量级客户端。这个客户端（用 C++ 或 Python 编写）不依赖任何 ROS 2 库，只负责解析网络数据并将其发布为 Humble 的 Topic。这样，两个发行版之间，就只有一条“裸数据”的管道，完全规避了 ABI 和序列化协议的冲突。

• 方案二：共享内存（Shared Memory）
  对于对实时性要求极高的场景（如运动控制），网络传输的延迟不可接受。这时，我们可以使用 POSIX 共享内存。在 Jazzy 环境中，一个节点将处理后的传感器数据（如sensor_msgs::msg::Imu的关键字段：linear_acceleration.x,angular_velocity.z）写入一块命名的共享内存区域（如/shm_imu_data）。在 Humble 环境中，另一个节点以只读方式映射同一块内存，并从中读取数据。由于共享内存操作的是原始字节，不涉及任何 C++ 对象或 ROS 消息的序列化，因此完全绕开了发行版的限制。我们曾用此方案，将一个 Jazzy 的视觉 SLAM 结果，以 < 1ms