RobotPerf架构总结

是 否 +2 论坛币

k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群

赵安豆老师微信：zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

立即领取

感谢您参与论坛问题回答

经管之家送您两个论坛币！

+2 论坛币

项目概述与核心目标

RobotPerf / benchmarks 是一个面向 ROS 2 的开源机器人性能基准测试框架，旨在通过标准化方法评估各类计算硬件（如 CPU、GPU、FPGA 及专用加速卡）在机器人任务中的实际表现。该项目为硬件选型与软件架构决策提供量化依据。

其设计遵循三大原则：技术中立性、厂商无关性以及实验可复现性。所有测试均基于真实或贴近实际应用场景的机器人工作流程，并以统一的 YAML 规范和自动化文档生成机制进行描述与管理。

benchmarks

顶层目录结构说明

项目的根目录包含以下主要组成部分：

• 项目总体介绍与资源汇总：涵盖项目背景、功能分类概览（包括感知、定位、控制、操作、导航等模块），并链接至详细的规范文档。

README.md

benchmarks/README.md

• 版本变更记录：记录各版本迭代内容与更新日志。

CHANGELOG.rst

• 开源许可证信息：明确项目的使用条款与授权方式。

LICENSE

• 可视化图表资源：存放各个 benchmark 对应的节点图与图标文件（PNG/SVG 格式），便于理解系统结构。

imgs/

核心规范体系

整个基准测试套件的设计依赖于一套严格的技术规范：

• Benchmark Specification：定义了基准测试的整体架构、术语体系以及单个 benchmark 应具备的组成要素。

benchmarks/README.md

• YAML 模板文件：作为标准化模板，用于指导每个 benchmark 描述文件的字段填写，确保格式一致性。

benchmarks/TEMPLATE.yaml

• 机器可读的 benchmark 描述文件：每个 benchmark 都需提供符合该模板的 YAML 文件，用以声明其结构与执行参数。

benchmark.yaml

基准测试实现分类

根据功能模块划分，当前已实现的 benchmark 被组织为多个类别，每类以特定前缀标识：

• 感知类（Perception）：前缀为 p*，涉及传感器数据处理与环境感知任务。

benchmarks/perception

a

• 定位类（Localization）：前缀为 l*，关注位姿估计与状态跟踪能力。

benchmarks/localization

b

• 控制类（Control）：前缀为 c*，评估运动控制算法的响应性能。

benchmarks/control

c

• 操作类（Manipulation）：前缀为 m*，聚焦机械臂操作与交互任务。

benchmarks/manipulation

d

• 中间件通信类：前缀为 w*，测试 ROS 2 内部消息传输效率与网络性能。

benchmarks/middleware

n

• 元基准与组合型测试：前缀为 e*，用于集成多个子任务形成复杂场景评测。

benchmarks/meta

m

• 公共工具与支撑库：提供通用测试辅助组件与共享代码模块。

benchmarks/other

命名规则与分类体系

依据规范文档（见下图），benchmark 的组织采用层级化命名策略：

benchmarks/README.md

功能类别划分（按机器人任务流）：

• 感知（Perception）

a

• 定位（Localization）

b

• 控制（Control）

c

• 操作（Manipulation）

d

• 导航（Navigation）

e

注：部分类别目前仅包含图标占位，具体 e* 类 benchmark 可能尚未合并至主分支。

Benchmark 唯一标识与包命名规则

每个 benchmark 拥有全局唯一的 ID，格式为：

<类别字母><序号>

示例包括：

a1

b3

c2

对应的 ROS 2 软件包名称遵循：

<ID>_<benchmark_name>

例如：

a1_perception_2nodes

b1_visual_slam

c1_rrbot_joint_trajectory_controller

该 ID 同时出现在 YAML 描述文件与 ROS 包名中，保障跨系统索引的一致性。

benchmark.yaml

单个 Benchmark 包的标准结构（基于 ROS 2 架构）

以典型 benchmark 包为例（如：

benchmarks/perception/a1_perception_2nodes

），其内部结构遵循标准 ROS 2 包组织方式：

基础包结构

• package.xml：声明包元信息及依赖关系。

package.xml

• CMakeLists.txt：配置构建过程，注册节点与 launch 文件安装路径。

CMakeLists.txt

核心实现组件

• 参考实现节点代码（通常位于 src/ 或 nodes/ 目录）：提供标准算法或流程的具体实现。

src/

include/

• 部分 benchmark 还包含仿真支持文件，如 Gazebo 场景配置或 RViz 显示设置。

config/

description/

worlds/

机器可读描述文件详解

每个 benchmark 必须包含一个 YAML 描述文件，内容依据统一模板定义，关键字段包括：

• id / name / description / short：基本元数据信息。
• graph：表示计算图结构的示意图，通常对应如下图形文件：

imgs/*.png

*.svg

• reproduction：详细说明实验复现步骤，可能包含针对特定平台（如 ROBOTCORE）的附加配置项。
• results[]：存储一组或多组测量结果，涵盖以下维度：
  • 测试类型（grey-box / black-box）

  type

  • 性能指标（延迟、功耗、吞吐量等）

  metric

  • 部署环境类型

  metric_unit

  hardware

  timestamp

  value

  note

  （如边缘设备、工作站、数据中心或云端）

  category

  • 数据源链接

  datasource

  （指向 rosbags 仓库中的测试数据路径）

人类可读文档生成机制

每个 benchmark 提供一份易于理解的说明文档：

• 内容涵盖功能说明与实测结果展示。
• 文档由机器可读的 YAML 文件自动转换生成，确保人机描述一致。

README.md

benchmark.yaml

执行与性能测量脚本

配套提供一组 ROS 2 launch 文件，用于启动与监控测试过程：

• 基础运行版本（不启用追踪或功耗采集）。
• 带 tracing 功能的版本（通常命名为：

launch/

trace_*

功能域子目录结构

感知

perception/

（a*）

典型示例包括：

a1_perception_2nodes

，用于评估两个节点之间图像处理流水线的性能基准，包含 C++ 组件及 tracing 启动配置。

a3_stereo_image_proc

/

a4_depth_image_proc

提供了相机模型 xacro、Gazebo 仿真环境和 RViz 配置文件，构建接近真实场景的视觉处理流程。

此外还有如

a5_resize

等较简单的图像处理链路，可用于测试单一算子在不同硬件平台或系统配置下的性能表现。

该模块架构特点在于依赖 ROS 图像消息流（如 sensor_msgs/Image）、结合仿真环境、rosbag 数据回放以及 tracing 技术进行综合性能分析。

定位

localization/

（b*）

涵盖

b1_visual_slam

、

b2_map_localization

、

b3_apriltag_detection

等典型用例，主要面向 SLAM、地图定位与 AprilTag 检测等任务的完整 pipeline。

通过标准数据集或仿真数据源进行回放，测量端到端延迟、吞吐量及资源占用情况，支持跨平台性能对比。

控制

control/

（c*）

包括

c1_rrbot_joint_trajectory_controller

、

c2_diffbot_diff_driver_controller

、

c3~c5_rrbot_forward_command_controller_*

等控制类 benchmark，均集成

benchmark.yaml

和

launch/

的 tracing 支持。

利用

rrbot

、

diffbot

等机器人模型与控制器插件，评估轨迹控制、速度/位置/加速度指令链的实时性与响应延迟等关键指标。

操作

manipulation/

（d*）

例如

d1_xarm6_planning_and_traj_execution

、

d2~d3_collision_checking_*

、

d4~d6_inverse_kinematics_*

等，覆盖路径规划、碰撞检测、正逆运动学等典型机械臂应用场景。

多数包含多个 Python 节点、描述文件和 trace launch 配置，用于量化不同算法实现或参数设置下的性能差异。

中间件

middleware/

（n*）

如

n1_intra_process

、

n2_inter_process

、

n3~n8_intra/inter_network(_security/_vpn)

等，专注于 ROS 2 通信层机制以及网络拓扑结构、安全策略对系统性能的影响。

在多种通信场景下开展基准测试，包括进程内、进程间、本地网络、跨网络甚至启用 VPN 与安全认证的情况，采用统一的 tracing 与指标采集体系输出结果。

元基准

meta/

（m*）

如

m1_turtle_tf2_demo

、

m2~m7_*

所示，旨在组合多个基础 benchmark 或为典型应用实例、教学案例提供可复用的基准版本。

其结构与其他类别相似，但更强调模块化组合与功能复用能力。

其他工具

other/

benchmark_utilities/

提供通用的 Python/ROS 2 工具函数与辅助节点，避免各 benchmark 中重复开发相同功能。

ros2benchmark/

构成一个通用的 benchmark 运行框架（orchestrator），负责：

• 统一配置并执行各类 benchmark
• 自动收集与整理运行结果

tracetools_benchmark/

（含 C/C++ 源码与头文件）基于

ros2_tracing

/LTTng 的底层 tracing 支持，提供插桩与事件采集所需的工具集。

rosgraph_png.py

可将 ROS 图计算结构自动生成 PNG 格式的可视化图表，对应

imgs/*.png

，便于从代码或 launch 文件快速生成系统架构图。

指标与测量方式（逻辑架构层）

依据

benchmarks/README.md

的规范，项目在逻辑层面抽象出性能测量的方法论：

指标体系（Metric）

• 延迟（latency / message latency / execution latency）
• 系统反应时间（含软件响应时间）
• 带宽 / 吞吐量（Messages/s、Bytes/s）
• 功耗 / 性能每瓦（power / performance-per-watt）
• 内存占用（memory）
• 与实时性、确定性相关的特性

测试类型（Type）

• 功能性能测试（Functional performance）
• 非功能性能测试（Non-functional performance），进一步细分为：
• Black-box：使用测试应用替代真实系统，从外部观测并采集性能指标
• Grey-box：在实际应用内部插入探针（probe），获取内部状态与事件时间戳（需代码插桩）

计算目标（Computing Targets）

涵盖边缘设备（edge）、工作站（workstation）、数据中心（datacenter）和云平台（cloud）等多种硬件环境。每项测试结果均标注所属计算类别，以便进行横向比较。

所有上述信息通过

benchmark.yaml

进行统一建模，并由工具链（

ros2benchmark

+ tracing + 可视化脚本）完成执行、数据采集及图表生成。

总结一句话：

benchmarks 项目的整体架构是在 ROS 2 基础上，将机器人完整的功能流水线划分为多个功能类别（如感知、定位、控制、操作、中间件等），每个 benchmark 以 ROS 2 包形式组织，并采用统一的

benchmark.yaml

方法进行性能建模与测量。

带功耗测量的版本

*_power.launch.py

。

针对不同计算硬件（Auto/GPU/FPGA）可生成相应的 trace 与执行流程。

部分包还附带

scripts/visualize_benchmark.sh

等辅助脚本，用于结果的可视化展示。

统一定义术语、分类、ID 规则以及指标体系，位于架构的顶层，通过

benchmarks/README.md

进行规范化处理； 在底层，集成了一系列公共支撑组件，包括

ros2benchmark

、

benchmark_utilities

、

tracetools_benchmark

等，提供运行时支持与性能测量能力。 整体架构结合规范定义、自动生成 README 文档功能，以及 launch、tracing、power 等自动化脚本模块，构建出一套具备可扩展性、可复现性且技术中立的机器人性能基准测试套件。

扫码加我 拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

分享0 收藏0 回帖

关键词：robot OBO BOT Rob TPE