[具身智能-664]：TogetheROS.Bot的出现的背景、发展历史、深度定制化解决什么问题以及与原始ROS2的对比。

TogetheROS.Bot（TROS.B）完整分析文档

包含：诞生背景、发展历史、深度定制解决的核心问题、与原生 ROS2 系统性对比。

一、TogetheROS.Bot 诞生背景

1. 产业大背景

1）ROS2 已经成为移动机器人、具身智能事实标准，但原生 ROS2 面向通用 x86 工控 / 高性能 ARM 设计，没有针对边缘 AI 芯片做软硬协同优化。

2）地平线推出 RDK 系列（旭日 X3/X5/Ultra），芯片核心算力来自BPU 神经网络加速器；开发者直接使用原生 ROS2 开发时存在巨大工程鸿沟：

• 开发者需要同时掌握：ROS2 开发 + BPU 底层 SDK、图像流水线、硬件编解码器、MIPI 驱动；
• 图像链路存在大量 CPU 拷贝、内存重复搬运，ARM CPU 负载居高不下；
• BPU 推理结果无法原生对接 ROS 消息体系，大量胶水代码，项目重复造轮子。

3）行业痛点：

巡检 AGV、人体跟随机器人、视觉抓取机械臂等产品落地周期长，中小团队缺少底层优化能力，硬件算力无法充分释放。

2. 技术层面矛盾

原生ROS2 架构硬件无关，抽象层隔离硬件能力；

地平线 RDK 具备专用硬件单元（BPU、VPU 硬件编解码、ISP 图像处理单元），通用 ROS2 无法调度这些硬件加速器，只能依靠 CPU 执行图像处理、编码、AI 前处理！！！。

核心诉求：保留 ROS2 标准生态，打通 ROS消息流水线与地平线芯片硬件加速单元，提供一套开箱即用的机器人软件发行版。

3. 产品定位澄清

TogetheROS.Bot不是独立操作系统，运行在 Ubuntu Linux 之上； 属于基于 ROS2 深度定制的机器人中间件发行版，完全兼容 ROS2 标准接口，面向地平线 RDK 硬件软硬协同优化。

二、发展历史（时间线）

1. 2021–2022预研阶段地平线内部基于 ROS2 Foxy 开展原型验证，解决 RDK X3 上图像链路、BPU 推理融合问题；内部名称 TogetherROS。

2. 2023 上半年：TogetheROS.Bot 1.x 正式发布

• 基于 ROS2 Foxy；源码托管在地平线内部 GitLab；
• 首发配套 RDK X3 开发板；
• 核心组件：hobot_dnn、hobot_sensor、hobot_codec，初步实现进程间零拷贝；
• 局限：封闭源码、仅适配老版本 RDK 系统镜像，X86 模拟器不完善。

1. 2023.05 TogetheROS.Bot 2.0 Beta 发布（重大里程碑）

• 代码迁移至 GitHub 开源，降低开发者准入门槛；
• 支持 RDK X3 Module；完善 X86 离线模拟器，支持图片回灌调试算法；
• 通信层大规模优化，完善 Zero-Copy 共享内存机制。

1. 2024 持续迭代 2.1 / 2.2 分支

• 支持 ROS2 Humumble；适配新硬件 RDK X5；
• 配套 NodeHub 应用市场，封装 SLAM、Nav2、人体跟随等成套应用；
• 完善 Web 渲染hobot_render，免除 RViz2 部署依赖。

1. 当前主线：2.x 系列（持续维护升级）✅ 新项目统一推荐 2.x； ❌ 1.x 停止新增功能，仅存量项目维护，不再推荐新项目使用。

命名说明：全称TogetheROS™·Bot，业内简称 TROS.B。

三、深度定制：到底解决原生 ROS2 哪些工程痛点

原生 ROS2 通用架构在边缘嵌入式 AI 机器人场景暴露一系列固有短板；

TROS.B 所有定制化改造全部围绕 RDK 芯片视觉 + AI 机器人链路展开。

痛点 1：BPU 模型推理难以接入ROS 消息流

原生 ROS2 问题ROS2 没有内置 AI 推理接口；开发者必须手动调用地平线 BPU SDK，自行实现图像消息裁剪、色域转换、模型输入封装、推理结果解析、消息封装，大量胶水代码；图像在 ROS 消息与 BPU 内存之间反复拷贝。

TROS.B 解决方案：hobot_dnn统一 ROS 风格推理节点，直接订阅 sensor_msgs 图像消息，内部自动对接 BPU；支持量化模型（BIN 模型）加载，推理结果直接输出标准 ROS 检测消息，打通感知链路。

痛点 2：图像数据流大量内存拷贝，CPU 负载高、时延大

原生 ROS2 问题

1. ROS2 intra-process 零拷贝仅限同一进程内；跨进程默认完整拷贝；
2. MIPI 相机输出 Bayer/YUV 原始图像，原生 ROS 没有硬件通路，需要 CPU 做色彩转换；
3. 多路图像传输场景下 ARM CPU 极易打满，引发帧丢失、导航卡顿。

TROS.B 解决方案：跨进程 Zero-Copy 共享内存扩展 ROS2 通信层，实现跨进程共享内存消息传输；相机原始帧直接在共享内存流转，传感器节点、DNN 推理、编码节点之间只传递指针，消除图像 Buffer 多次复制。

痛点 3：硬件编解码器、ISP 无法被 ROS 直接调用

原生 ROS2 问题ROS 社区图像编码包（image_transport）基于 FFmpeg软编码，极度消耗 ARM CPU；无法调用芯片内置 VPU 硬件 H.264/H.265 编码器。

TROS.B 解决方案：hobot_codec+hobot_cv封装硬件编解码、硬件图像缩放、色域转换（Bayer→YUV→RGB）；所有算子卸载到硬件单元，CPU 仅负责业务逻辑。

痛点 4：机器人传感器驱动碎片化、时间戳同步困难

原生 ROS2 问题MIPI 相机、RGBD、IMU缺少统一适配驱动；各传感器时钟源不一致，多传感器融合（VSLAM、3D 检测）时间对齐难度极高。

TROS.B 解决方案：hobot_sensor预适配 RDK 配套全系传感器；统一硬件时间戳采集，提供同步机制，降低多传感器融合开发难度。

痛点 5：嵌入式端可视化调试门槛高

原生 ROS2 问题RViz2 依赖桌面 GUI，ARM 板运行卡顿；远程可视化需要配置网络、压缩图像，部署繁琐。

TROS.B 解决方案：hobot_render内置 Web 服务，浏览器直接查看图像、检测框、点云；无需 RViz，适合嵌入式设备现场调试。

痛点 6：缺少面向机器人的成套参考应用

原生 ROS2 只提供基础组件，SLAM、人体跟随、视觉巡线等方案需要开发者自行整合。 TROS.B 内置 Boxs 算法库 + Apps 案例：开箱即用 2D SLAM、Nav2 导航、目标检测、人体关键点、语音交互等完整 Launch 工程。

痛点 7：缺少端侧仿真调试手段

原生 ROS2 仿真依赖 Gazebo，资源消耗巨大；TROS.B 提供 X86 模拟器，PC 端灌入图片 / 视频离线调试 AI 算法，验证完成后几乎零修改迁移到 RDK 硬件。

四、TogetheROS.Bot vs 原生 ROS2 系统性对比

前提：TROS.B保持 ROS2 标准消息、rclcpp/rclpy API 完全兼容，原有 ROS2 功能包（Nav2、MoveIt2）可以直接编译运行。

表格

五、关键认知误区澄清

1. ❌ TROS.B = 新操作系统 ✅ 运行于 Ubuntu 之上，是 ROS2 增强发行版，不是 OS。

2. ❌ TROS.B 脱离标准 ROS2，代码不能互通 ✅ 消息类型、rclcpp/rclpy 完全兼容；标准 ROS2 包可以直接运行。

3. ❌ 只能使用 TROS 内置节点，不能自定义开发 ✅ 用户可以自由编写标准 ROS2 节点，自由组合原生 ROS 功能包与 hobot 系列组件。

4. ❌ 在非地平线开发板上运行也有性能优势 ✅ 在其他 ARM/X86 平台，硬件加速组件失效，仅相当于普通 ROS2，失去核心价值。

六、补充工程结论（落地参考）

• 新项目使用 RDK X3/X5/Ultra 做视觉机器人：优先选择 TogetheROS.Bot 2.x；
• 硬件不是地平线芯片：直接使用原生 ROS2 Humble/Jazzy；
• 架构迁移：原有标准 ROS2 工程，迁移至 TROS.B 基本不需要大规模修改业务逻辑，只需要替换图像采集、推理部分节点为 hobot 组件。