1. 项目概述：Bouncy Bolson 是什么，为什么它值得被认真对待
你可能在翻查 ROS 2 历史文档时，偶然撞见 “Bouncy Bolson” 这个名字——听起来像某个西部小镇的绰号，又带点物理弹跳的俏皮感。但对真正做过 ROS 2 早期系统集成、跨平台部署或底层中间件适配的人来说， Bouncy Bolson（代号 bouncy）不是一段被遗忘的旧代码，而是一块关键的承重梁 。它是 ROS 2 的第二个正式发行版，发布于 2018 年 7 月，紧随 Ardent Apalone 之后，却首次将 ROS 2 从“概念验证阶段”推向“可工程化落地阶段”的分水岭。它不提供炫酷的新算法，也不主打云原生或 AI 集成——它的价值藏在那些你日常调试时不会多看一眼、但一旦缺失就寸步难行的底层契约里：比如让 C++ 节点能真正通过命令行接收参数，比如让 launch 文件第一次具备条件判断和嵌套加载能力，比如让 Fast-RTPS、Connext、OpenSplice 三家主流 DDS 实现首次在同一套构建体系下稳定共存。我当年在一台 ARM64 架构的 Jetson TX2 上为农业机器人部署 ROS 2 控制栈，就是从 bouncy 开始啃起的。当时没有现成的 Debian 包，只能手动编译整个 ament 工具链、patch Ogre 的 OpenGL ES 兼容层、反复调整 Poco 的线程模型以适配 RTI Connext 的实时性要求。这个过程痛苦，但每一步踩过的坑，都让我彻底理解了 ROS 2 的模块边界在哪里、DDS 分区机制为何被弃用、以及为什么 colcon 会取代 ament_tools 成为事实标准。今天回看 bouncy，它早已进入官方定义的“End-of-Life”状态，不再接收安全更新；但它的设计决策、版本约束、平台支持逻辑，至今仍深刻影响着 ROS 2 Foxy、Humble 甚至 Rolling 的架构演进路径。如果你正在维护一个运行在老旧工业 PC（Windows 10 + VS2017）上的 ROS 2 系统，或者需要为定制硬件（如基于 Debian Stretch 的嵌入式主控）做最小可行移植，bouncy 的文档不是历史遗迹，而是最贴近硬件真相的操作手册。它解决的从来不是“未来该怎么做”，而是“此刻在受限环境下，怎样让 ROS 2 真正跑起来”。
2. 整体设计思路与平台支持逻辑拆解
2.1 为什么是这四个平台？背后是现实主义的工程取舍
ROS 2 的每一次发行版，其平台支持列表都不是随意圈定的，而是由三股力量共同拉扯出的平衡点：上游操作系统生命周期、下游硬件厂商的驱动支持成熟度、以及 OSRF 自身的 CI/CD 资源上限。Bouncy Bolson 的四平台组合——Ubuntu 18.04（Bionic）、Ubuntu 16.04（Xenial）、macOS 10.12（Sierra）、Windows 10（VS2017）——正是这种现实主义哲学的集中体现。
先看 Ubuntu Bionic。它于 2018 年 4 月发布，LTS 支持至 2023 年，是当时最“新鲜”的长期支持版。选择它作为主力平台，意味着 ROS 2 团队可以大胆采用较新的编译器特性（GCC 7.3+）和系统库（如 libstdc++ 的 C++14 完整实现），同时规避掉 Xenial 中已知的 glibc 2.23 内存管理缺陷。更重要的是，Bionic 的内核（4.15）对实时补丁（PREEMPT_RT）的支持更稳定，这对后续 ROS 2 在工业控制场景的应用至关重要。所以，bouncy 对 Bionic 的支持是“全栈式”的：不仅提供预编译的 amd64/arm64 Debian 包，连依赖项（如 CMake 3.10.2、Python 3.6.5）的版本都精确锁定到 Bionic 官方仓库中可用的最新稳定版，避免用户陷入“升级 CMake 就崩掉 Qt”的经典困境。
再看 Ubuntu Xenial。它虽已进入生命周期尾声（2016 年发布），但在 2018 年仍是大量工业 PC 和嵌入式板卡（如 Intel NUC、BeagleBone AI）的默认系统。放弃 Xenial 意味着将整个存量市场拒之门外。因此，bouncy 采取了务实策略：“ 源码级兼容，二进制级放弃 ”。文档中明确标注 “[s] Compilation from source, the ROS buildfarm will not produce any binary packages for these platforms”，这句话的潜台词是：我们保证你的代码能在 Xenial 上编译通过，但不会为你打包好所有依赖。你需要自己用 apt 安装 Xenial 的 CMake 3.5.1（而非更高版本），手动编译 Poco 1.8.0（因为 Xenial 仓库只有 1.7.x），并接受 OpenCV 2.4.9 带来的 API 差异。这不是偷懒，而是将有限的 CI 资源聚焦在 Bionic 这个“未来主战场”，同时为老设备用户提供一条清晰、可控的“自力更生”路径。
macOS Sierra 和 Windows 10 的入选，则直指 ROS 2 的跨平台野心。Sierra（2016 年发布）是苹果系统中第一个全面拥抱 Metal 图形 API 的版本，而 ROS 2 的可视化工具（如 rviz2 的早期原型）严重依赖 Ogre 渲染引擎。bouncy 强制要求 Ogre 1.10*（非 macOS 官方仓库版，而是 OSRF 维护的定制包），正是因为原生 Sierra 的 Ogre 1.8 无法正确处理 DDS 分区映射。同理，Windows 10 + VS2017 的组合，是微软在 2017 年推出的首个完整支持 C++14 标准的 Visual Studio 版本，且其 MSVCRT 运行时与 Windows 10 的内核调度器协同更优。bouncy 文档中特意强调 “Binary packages as well as instructions for how to compile from source are provided”，其深意在于：Windows 用户不必再像 Ardent 时代那样，必须手动配置数百个环境变量才能启动一个 talker，而是可以通过 Chocolatey 一键安装核心依赖（CMake、Python、Poco），再用 colcon 构建——这是 ROS 2 向 Windows 生态迈出的关键一步。
提示：当你看到文档中 “Recommended Support” 列标有 [s] 时，请立刻提高警惕。这并非“建议支持”，而是“ 有条件支持 ”的委婉表达。例如 Debian Stretch 被列为推荐支持，但其 CMake 3.7.2 版本低于 Bionic 的 3.10.2，这意味着你在 Stretch 上编译某些使用了 CMake 3.10 新特性的第三方包（如某些传感器驱动）时，会直接报错。此时，你必须手动升级 CMake 至 3.10+，而这又可能引发与系统 Qt 5.7.1 的 ABI 不兼容问题。这种“支持”本质是一张需自行填坑的地图。
2.2 语言与依赖版本的硬性门槛：不是为了炫技，而是为了确定性
ROS 2 的设计哲学之一，是“ 确定性优先于先进性 ”。bouncy 对 C11、C++14、Python 3.5 的最低要求，并非追赶潮流，而是为了解决 Ardent 中暴露的致命不确定性。
C++14 的强制要求，核心在于 std::make_unique 和 auto 类型推导的稳定性 。在 Ardent 中，部分节点类使用了 GCC 4.9 的实验性 C++14 特性，导致在 Clang（macOS 默认编译器）下编译失败。bouncy 将标准统一提升至 C++14，并明确要求编译器必须通过 __cplusplus >= 201402L 宏检测，确保 std::shared_ptr 的线程安全构造、 constexpr 函数的递归展开等关键行为在所有平台一致。我曾遇到一个诡异问题：在 Ubuntu Xenial 上，同一个 rclcpp::Node 构造函数，在 GCC 5.4 下正常，在 Clang 3.8 下崩溃。根源就是 Ardent 未严格约束 C++ 标准，导致不同编译器对同一段代码的解释出现分歧。bouncy 用硬性门槛堵死了这条路。
Python 3.5 的选择则关乎 异步 I/O 的基石 。ROS 2 的 rclpy 客户端库重度依赖 asyncio ，而 Python 3.5 是首个将 async / await 语法作为正式关键字引入的语言版本。若允许 Python 3.4，开发者就必须用 @asyncio.coroutine 和 yield from 这种冗长写法，不仅增加学习成本，更易在协程嵌套时引发 RuntimeWarning: coroutine 'xxx' was never awaited 这类难以追踪的 bug。bouncy 强制 3.5+，等于为整个 Python 生态划定了一个干净、无歧义的异步编程起点。
依赖项的版本锁定更是精妙。以 CMake 为例：Bionic 要求 3.10.2，Xenial 只要 3.5.1。表面看是向下兼容，实则是利用 CMake 的“ 功能
扫一扫
483
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
