企业官网建设流程全解析

1. 为什么这个融合不是“把两个数据加起来”那么简单？

在ROS2机器人开发里，看到“IMU+里程计融合”这六个字，很多刚从ROS1转过来的朋友第一反应是：不就是订阅两个话题，写个简单的加权平均或者取个中位数？我最早在调试一台AGV小车时也这么干过——直接把/odom的x/y位置和/imu/data的yaw角拼在一起发给导航栈，结果小车在直行时yaw角疯狂抖动，转弯时位置漂移得像喝醉，rviz2里轨迹画出一条毛线团。后来翻了三天robot_localization的源码才明白：这不是数据拼接，而是一场精密的时空校准与不确定性博弈。

核心关键词robot_localization不是个普通节点，它是基于**扩展卡尔曼滤波（EKF）或无迹卡尔曼滤波（UKF）**构建的状态估计算法框架，本质是在处理“带误差的观测”与“带模型偏差的预测”之间的动态平衡。IMU提供高频（通常100Hz+）但存在零偏漂移和积分误差的角速度/加速度；轮式里程计提供低频（10–50Hz）、受打滑和轮径误差影响的位置/速度估计；两者误差特性完全相反——一个高频但漂移，一个低频但累积。直接相加等于把两份“带不同病灶的体检报告”强行合并成一份诊断书，结果只会更混乱。

真正起作用的是协方差矩阵的数学表达：robot_localization不是看数值本身，而是看每个数值背后那个椭圆状的“不确定性区域”。比如IMU的yaw角协方差可能是0.01（标准差0.1弧度≈5.7度），而里程计的x方向协方差可能是0.05（标准差0.22米）。EKF会自动给yaw角更高权重，因为它的“可信圈”更小；当小车静止时，IMU的角速度接近零，此时EKF会大幅降低yaw更新频率，转而信任里程计的微小位移变化——这种动态权重切换，是手写加权平均永远做不到的。

你可能会问：既然这么复杂，为什么不用VINS-Fusion这类视觉惯性方案？答案很实在：成本、实时性、鲁棒性三角制约。VINS需要RGB-D或双目相机+高算力GPU，而一台工业AGV可能只配一个MPU6050+编码器，CPU是ARM Cortex-A53；robot_localization在树莓派4上跑EKF稳稳压在15ms内，且对光照、纹理缺失、运动模糊完全免疫。它解决的不是“最高精度”，而是“在有限硬件下最可靠的定位基线”——这才是绝大多数真实产线、服务机器人、教育平台的真实战场。

所以当你看到标题里的“手把手”，它真意是：带你亲手拧开EKF的黑箱，看清每个参数怎么影响那个椭圆的形状、大小、旋转角度，而不是复制粘贴一段launch文件就以为搞定了。接下来所有操作，都围绕一个目标：让rviz2里那个蓝色小箭头，稳稳地走在你心里预设的轨迹上，不跳、不抖、不漂。

2. robot_localization核心设计逻辑与选型依据

2.1 EKF vs UKF：不是性能越强越好，而是误差模型越匹配越稳

robot_localization提供两种滤波器：ekf_node和ukf_node。新手常误以为UKF（无迹卡尔曼）更先进，就默认选它。我在调试一台履带式巡检机器人时吃过亏——初期用UKF，结果在颠簸路面出现周期性位置震荡，幅度达±0.8米。后来切回EKF，震荡消失，定位反而更平滑。原因在于：UKF对非线性模型更鲁棒，但对噪声建模更敏感；EKF对线性化假设更宽容，更适合轮式机器人这种运动模型相对规整的场景。

轮式机器人的运动学模型本质是线性的（x'=v·cosθ, y'=v·sinθ, θ'=ω），IMU测量模型也是线性的（加速度=重力+线加速度，角速度=真实角速度+零偏）。EKF通过一阶泰勒展开做线性化，误差可控；而UKF用sigma点采样，当IMU零偏突变（比如机器人撞墙瞬间）或里程计信号断续（轮子短暂打滑）时，sigma点分布会失真，导致状态协方差被错误放大，进而引发滤波器发散。

实测对比数据（同一台TurtleBot3 Burger，ROS2 Humble）：

结论很清晰：对轮式/履带式机器人，EKF是更稳、更省资源的选择。UKF真正发挥优势的场景是无人机悬停（强非线性气流扰动）、机械臂末端定位（关节耦合非线性），而非地面移动机器人。所以本教程全程以ekf_node为基准，参数配置也按EKF特性优化。

2.2 为什么必须用两个独立滤波器？单滤波器会埋下定时炸弹

网上很多教程教你在同一个EKF里同时融合IMU和odom，看似简洁，实则危险。我在帮一家仓储机器人公司做故障复现时发现：他们单滤波器配置下，小车在长走廊运行20分钟后，Y轴位置突然跳变1.2米——日志显示是IMU的linear_acceleration.z值异常飙升至15m/s²（远超重力加速度9.8），触发了EKF的异常观测剔除机制，但因odom和IMU共用同一状态向量，剔除IMU数据时连带抑制了odom的y方向更新，导致位置估计“卡死”在错误值上。

正确做法是分层滤波：底层用odom+IMU角速度做2D位置/朝向估计，顶层用IMU全姿态+GPS（如有）做3D全局校正。robot_localization官方推荐架构正是如此：

• ekf_local_filter：输入/odom（仅x,y,θ）和/imu/data（仅angular_velocity.z,orientation.yaw），输出/odometry/filtered，专注解决局部定位漂移；
• ekf_global_filter：输入/odometry/filtered、/imu/data（全四元数）、/gps/fix（如有），输出/odometry/global，解决全局尺度漂移。

这样设计的物理意义是：把高频但易漂移的IMU角速度，和低频但稳定的odom位置，在各自最擅长的维度上发挥价值。/odom的x/y提供位置锚点，/imu/data的angular_velocity.z提供精确转向速率，两者互补；而/imu/data的orientation四元数只用于全局滤波层，避免局部层被IMU姿态噪声污染。

提示：/odom话题必须来自轮式编码器或激光里程计（如slam_toolbox），不能是/tf推导的伪里程计。我见过三次故障都是因为用户把/tf的base_link→odom变换反向当作/odom发布，导致EKF收到的是“已修正过的位姿”，再融合IMU就成了双重修正，结果剧烈震荡。

2.3 坐标系对齐：不是命名规范问题，而是物理世界映射问题

ROS2中坐标系（frame_id）不是字符串标签，而是刚体变换的数学载体。robot_localization要求所有输入数据的frame_id必须与world_frame和base_link_frame构成闭环。常见错误是把IMU的frame_id设为imu_link，却没在URDF中定义imu_link→base_link的静态变换——EKF会静默忽略该IMU数据，因为无法将IMU测量转换到机器人本体坐标系。

正确流程必须三步闭环：

1. 硬件安装确定物理偏移：IMU安装在机器人顶部中心？还是偏左15cm？用卷尺实测，记录为x=0.15, y=0.0, z=0.3, roll=0, pitch=0, yaw=0；
2. URDF中声明静态链接：在<robot>内添加：

<link name="imu_link"/> <joint name="imu_joint" type="fixed"> <parent link="base_link"/> <child link="imu_link"/> <origin xyz="0.15 0 0.3" rpy="0 0 0"/> </joint>

3. EKF配置中指定imu0_frame_id: imu_link，并确保base_link_frame: base_link，world_frame: odom（或map）。

我曾调试一台配送机器人，IMU装在底盘上方10cm处，但URDF里写成z=0.0，结果EKF把IMU的加速度测量当作质心加速度处理，转弯时产生虚假侧向力，导致位置估计向弯道外侧持续偏移。用ros2 run tf2_tools view_frames生成坐标系树，确认imu_link→base_link变换存在且数值正确，是上线前必做的检查项。

3. 核心参数详解与避坑实操指南

3.1frequency与sensor_timeout：时间窗口不是越大越好

EKF的frequency参数（单位Hz）常被误解为“滤波器运行频率”，实际它是状态预测步长的倒数。设为30Hz，意味着每33.3ms做一次预测+更新循环。但若你的IMU发布频率是200Hz，odom是10Hz，frequency设太高会导致大量IMU数据被丢弃；设太低则预测滞后，跟不上快速转向。

经验公式：frequency = min(1 / (odom_update_interval), 1 / (imu_update_interval * 0.3))

• odom更新间隔：若编码器每0.1秒发一次，间隔=0.1s → 10Hz
• IMU更新间隔：200Hz → 0.005s，乘0.3≈0.0015s → 666Hz
  取min=10Hz，但需留余量，故设frequency: 20.0

sensor_timeout更关键：它定义“某个传感器数据多久没来就算失效”。默认值30.0秒，对IMU极危险——IMU断连30秒后，EKF仍用旧零偏预测，位置会指数级漂移。实测：IMU断连10秒，小车定位误差已达1.8米。应设为sensor_timeout: 0.1（100ms），即连续100ms没收到IMU，就冻结其贡献，纯靠odom维持。

注意：sensor_timeout必须小于frequency的倒数。若frequency: 20.0（周期50ms），sensor_timeout设为0.1s（100ms）合理；若设为0.02s（20ms），则因IMU数据处理延迟（通常3–5ms），EKF会频繁判定IMU超时，导致融合失效。

3.2 协方差矩阵：不是抄模板，而是用实测数据填空

EKF的鲁棒性90%取决于协方差初始化。网上流传的“万能协方差”如[0.01, 0, 0, 0, 0, 0]全是毒药。IMU的orientation_covariance必须反映真实传感器精度。以MPU6050为例，厂商手册标明yaw角随机游走0.1°/√h，换算成rad/s²：

• 0.1°/√h = 0.1 × π/180 / √3600 ≈ 4.85e-6 rad/s²
• 对应协方差 = (4.85e-6)² ≈ 2.35e-11

但实测发现：MPU6050在静止时yaw角标准差约0.02rad（1.15°），协方差应设为0.0004。我用ros2 topic echo /imu/data录30秒静止数据，用Python计算：

import numpy as np # 假设data是30秒的四元数列表 yaw_list = [2*np.arctan2(qz, qw) for qw,qx,qy,qz in data] print(np.var(yaw_list)) # 输出0.000382 → 设orientation_covariance[0] = 0.0004

同样，里程计/odom的pose.covariance必须实测：让小车直线行走10米，用激光雷达SLAM建图作为真值，对比/odom输出位置，计算x方向标准差。若为0.05m，协方差设0.0025；若为0.12m（老旧编码器），就得设0.0144。协方差设小了，EKF过度信任该传感器，噪声会被放大；设大了，EKF忽视有效信息，融合效果归零。

3.3differential与relative模式：何时该关掉“自动微分”

differential: true是robot_localization的默认行为，它把/odom的twist（速度）当作绝对速度处理，自动对速度积分得到位置。但问题在于：轮式里程计的twist本身就是由编码器脉冲微分而来，再积分等于二次微分，噪声被平方放大。

实测对比（同一段10米直线）：

• differential: true：位置误差RMS=0.082m
• differential: false：直接使用/odom的pose（位置），误差RMS=0.035m

原因：编码器原始脉冲经硬件滤波后，pose是经过低通处理的位置，而twist是脉冲差分，高频噪声显著。因此，只要/odom话题包含有效pose字段，务必设differential: false。

relative: true则用于IMU：当IMU的orientation是相对于启动时刻的相对角度时启用。但多数IMU驱动（如ros2_imu_driver）发布的是绝对四元数（w,x,y,z），此时必须relative: false。设错会导致yaw角随时间线性漂移——因为EKF把相对角度当绝对值累加。

3.4two_d_mode：2D模式不是省事，而是规避Z轴灾难

two_d_mode: true强制EKF只估计x,y,θ，忽略z,roll,pitch。这不仅是性能优化，更是安全设计。IMU的linear_acceleration.z在机器人运动时受振动干扰极大（实测峰值达±5m/s²），若开启3D模式，EKF会尝试用这些噪声数据修正z轴位置，导致整个状态向量协方差爆炸，最终拖垮x,y估计。

验证方法：用ros2 topic hz /odometry/filtered监控输出频率，若开启3D后频率骤降50%，基本可判定z轴噪声触发了EKF内部保护机制。two_d_mode: true后，EKF内部状态维度从6D（x,y,z,roll,pitch,yaw）降至3D，计算量减少70%，且彻底屏蔽z轴干扰。

实操心得：即使你的机器人有升降机构，也不要为z轴启用IMU融合。升降动作应由独立执行器控制，z轴位置由电机编码器或激光测距仪提供，与IMU解耦。融合的唯一目标是让x,y,θ稳如磐石。

4. 完整实操流程与关键环节实现

4.1 环境准备与依赖安装（Ubuntu 22.04 + ROS2 Humble）

先确认系统环境：

source /opt/ros/humble/setup.bash ros2 --version # 应输出ros2 0.0.0-humble

安装robot_localization核心包（Humble版本已内置，无需额外apt）：

# 验证是否已安装 ros2 pkg list | grep robot_localization # 若无输出，手动编译（极少情况） git clone https://github.com/cra-ros-pkg/robot_localization.git -b humble-devel cd robot_localization && colcon build --symlink-install source install/setup.bash

关键依赖检查——IMU驱动必须发布标准sensor_msgs/msg/Imu：

# 启动IMU节点（以mpu6050为例） ros2 launch mpu6050_driver mpu6050.launch.py # 检查消息结构 ros2 topic echo /imu/data --once | head -n 20 # 必须包含：orientation, angular_velocity, linear_acceleration, covariance字段

里程计节点需发布nav_msgs/msg/Odometry，且header.frame_id为odom，child_frame_id为base_link：

# 检查odom话题 ros2 topic info /odom # 输出应含：Publisher count: 1, Subscription count: 0（说明有发布者） ros2 topic echo /odom --once | grep -E "(frame_id|child_frame_id)" # 正确输出：frame_id: "odom", child_frame_id: "base_link"

提示：若/odom的child_frame_id是wheel_left_link等非base_link，必须用robot_state_publisher或static_transform_publisher补全base_link→wheel_left_link变换，否则EKF无法关联。

4.2 EKF配置文件编写：从零开始填满17个关键参数

创建config/ekf.yaml，逐项解析：

# --- 滤波器基础配置 --- frequency: 20.0 # 每50ms执行一次预测/更新 sensor_timeout: 0.1 # IMU超时100ms即冻结 transform_time_offset: 0.0 # TF变换时间偏移，一般0.0 print_diagnostics: true # 开启诊断，输出到/rosout debug: false # 调试模式，生产环境关闭 publish_tf: true # 发布odom→base_link TF publish_acceleration: false # 不发布加速度，除非需要 # --- 坐标系定义 --- world_frame: odom # 全局坐标系，与/odom一致 odom_frame: odom # 里程计坐标系 base_link_frame: base_link # 机器人本体坐标系 global_frame: map # 若有SLAM，此处为map # --- 输入源配置 --- # IMU输入 imu0: /imu/data imu0_config: [false, false, false, # x,y,z位置不使用 true, true, true, # roll,pitch,yaw使用 false, false, false, # x,y,z线速度不使用 true, true, true, # roll,pitch,yaw角速度使用 false, false, false] # x,y,z线加速度不使用 imu0_differential: false # IMU姿态不微分 imu0_relative: false # IMU姿态为绝对值 imu0_pose_rejection_threshold: 0.8 # 姿态跳跃阈值（rad），防突变 imu0_twist_rejection_threshold: 0.8 # 角速度跳跃阈值（rad/s） imu0_linear_acceleration_rejection_threshold: 0.9 # 加速度跳跃阈值（m/s²） # --- 协方差设置（实测值！）--- imu0_pose_covariance_diagonal: [0.0004, 0.0004, 0.0004, # roll,pitch,yaw 0.001, 0.001, 0.001] # 角速度协方差（略大） imu0_twist_covariance_diagonal: [0.001, 0.001, 0.001, # 角速度协方差 0.0001, 0.0001, 0.0001] # 线加速度协方差（极小） # --- 里程计输入 --- odom0: /odom odom0_config: [true, true, false, # x,y,z位置使用x,y，禁用z false, false, true, # roll,pitch,yaw只用yaw false, false, false, # x,y,z线速度禁用（用pose更稳） false, false, false, # roll,pitch,yaw角速度禁用 false, false, false] # 线加速度禁用 odom0_differential: false # 关键！禁用微分，用pose odom0_relative: false # odom pose为绝对位置 odom0_pose_rejection_threshold: 2.0 # 位置跳跃阈值（m），防里程计跳变 # --- 协方差设置 --- odom0_pose_covariance_diagonal: [0.0025, 0.0025, 0.0004, # x,y,yaw（实测0.05m/0.02rad） 0.0, 0.0, 0.0] # roll,pitch置0（2D模式）

参数填写逻辑：

• imu0_config数组12位，对应[x, y, z, roll, pitch, yaw, vx, vy, vz, vroll, vpitch, vyaw]，true表示使用该维度；
• odom0_config同理，但vx,vy,vz设false，因differential: false已禁用速度积分；
• rejection_threshold设为协方差对角线元素的2倍，防传感器瞬态噪声触发误剔除。

4.3 Launch文件编写与TF树构建

创建launch/ekf_launch.py：

from launch import LaunchDescription from launch_ros.actions import Node from launch.actions import DeclareLaunchArgument from launch.substitutions import LaunchConfiguration def generate_launch_description(): use_sim_time = LaunchConfiguration('use_sim_time', default='false') return LaunchDescription([ DeclareLaunchArgument( 'use_sim_time', default_value='false', description='Use simulation time if true'), # 启动EKF节点 Node( package='robot_localization', executable='ekf_node', name='ekf_filter_node', output='screen', parameters=[{ 'use_sim_time': use_sim_time, 'robot_description': '', # 不需要URDF 'tf_prefix': '', 'frequency': 20.0, 'sensor_timeout': 0.1, 'two_d_mode': True, 'map_frame': 'map', 'odom_frame': 'odom', 'base_link_frame': 'base_link', 'world_frame': 'odom', 'transform_time_offset': 0.0, 'print_diagnostics': True, 'debug': False, 'publish_tf': True, 'publish_acceleration': False, 'imu0': '/imu/data', 'imu0_config': [False, False, False, True, True, True, False, False, False, True, True, True], 'imu0_differential': False, 'imu0_relative': False, 'imu0_pose_rejection_threshold': 0.8, 'imu0_twist_rejection_threshold': 0.8, 'imu0_linear_acceleration_rejection_threshold': 0.9, 'imu0_pose_covariance_diagonal': [0.0004, 0.0004, 0.0004, 0.001, 0.001, 0.001], 'imu0_twist_covariance_diagonal': [0.001, 0.001, 0.001, 0.0001, 0.0001, 0.0001], 'odom0': '/odom', 'odom0_config': [True, True, False, False, False, True, False, False, False, False, False, False], 'odom0_differential': False, 'odom0_relative': False, 'odom0_pose_rejection_threshold': 2.0, 'odom0_pose_covariance_diagonal': [0.0025, 0.0025, 0.0004, 0.0, 0.0, 0.0], }], remappings=[('/odometry/filtered', '/odometry/filtered')], ), # 发布静态TF：base_link → imu_link（根据实际安装调整） Node( package='tf2_ros', executable='static_transform_publisher', name='imu_base_tf', arguments=['0.15', '0.0', '0.3', '0', '0', '0', 'base_link', 'imu_link'] ), ])

TF树必须满足：odom → base_link → imu_link。static_transform_publisher参数顺序为x y z roll pitch yaw parent child，单位：米/弧度。

启动命令：

ros2 launch your_package ekf_launch.py

验证TF树：

ros2 run tf2_tools view_frames # 生成frames.pdf，打开检查是否有odom→base_link→imu_link链路

4.4 实时监控与效果验证：三步法确认融合成功

第一步：检查EKF诊断输出
监听/diagnostics话题：

ros2 topic echo /diagnostics

正常输出应含：

- name: "robot_localization: ekf_local_filter" level: 0 # OK message: "OK" values: - key: "Period (real-time)" value: "0.0498" - key: "Period (simulated)" value: "0.0" - key: "Frequency (real-time)" value: "20.08"

若level: 2（ERROR）且message含No measurements received，检查/imu/data和/odom是否发布。

第二步：对比原始与融合后轨迹
启动rviz2，添加两个Odometry显示：

• Topic:/odom，Color: Red
• Topic:/odometry/filtered，Color: Blue
  让小车沿直线行走10米，观察蓝色轨迹是否比红色更直、更细。转弯时，蓝色箭头应平滑转向，红色箭头可能出现锯齿。

第三步：定量误差分析
若有激光SLAM真值（/slam/pose），用ros2 topic hz和ros2 topic delay对比：

# 检查延迟 ros2 topic delay /odometry/filtered /slam/pose # 正常值：< 0.05s # 计算同步误差 ros2 topic echo /odometry/filtered --no-arr --field header.stamp.sec | head -n 100 > filtered.txt ros2 topic echo /slam/pose --no-arr --field header.stamp.sec | head -n 100 > slam.txt # 用Python计算位置差（略）

实测典型效果（TurtleBot3 + MPU6050）：

5. 常见问题与排查技巧实录

5.1 “蓝色小箭头原地打转”：IMU零偏未校准的典型症状

现象：rviz2中/odometry/filtered的箭头在原地高速旋转，位置不变。
日志特征：/diagnostics中robot_localization状态为WARN，message含Large orientation jump detected。

根本原因：IMU未做零偏校准，静止时angular_velocity.z输出非零均值（如+0.05rad/s）。EKF将其当作真实角速度积分，导致yaw角每秒增加0.05rad，20秒后转完一圈。

解决方案：

1. 硬件级校准：MPU6050需上电静置10秒，让内部陀螺仪自校准；
2. 软件级补偿：用rqt_reconfigure动态调整IMU驱动的gyro_bias_x/y/z参数；
3. EKF兜底：在ekf.yaml中增大imu0_twist_rejection_threshold至1.5，并启用imu0_remove_gravitational_acceleration: true（若IMU驱动支持）。

实操心得：我习惯在启动EKF前，先运行ros2 topic echo /imu/data --no-arr | grep angular_velocity，静置30秒，用awk '{sum+=$3} END {print sum/NR}'计算z轴均值。若绝对值>0.01rad/s，必须校准后再启动EKF。

5.2 “小车走直线却画曲线”：里程计与IMU坐标系未对齐

现象：小车沿直线前进，rviz2中蓝色轨迹呈正弦波形，振幅随速度增大。
日志特征：/diagnostics无报错，但/odometry/filtered的twist.angular.z持续输出非零值。

根因：IMU安装偏航角未在URDF中声明。例如IMU实际安装偏右10°（yaw=-0.1745rad），但URDF中<origin rpy="0 0 0"/>，导致EKF把IMU的angular_velocity.z当作机器人本体角速度，而实际是v×sin(10°)的侧向分量。

验证方法：

ros2 run tf2_tools echo /base_link /imu_link # 输出应含：rotation: (0.0, 0.0, -0.1745) # 即yaw=-10°

若输出为(0,0,0)，说明TF缺失。

修复步骤：

1. 用卷尺实测IMU相对base_link的偏移；
2. 修改URDF中<origin>的rpy值；
3. 重启robot_state_publisher；
4. 用view_frames确认新TF生效。

5.3 “融合后比单用更差”：协方差设置违背物理现实

现象：开启EKF后，定位误差反而比单用/odom大2倍。
日志特征：/diagnostics中robot_localization状态为OK，但/odometry/filtered协方差矩阵对角线元素异常大（如pose.covariance[0] > 1.0）。

典型错误：

• 抄袭网络模板，把IMU的orientation_covariance设为[1e-6, ...]，但实测MPU6050为0.0004；
• 把里程计pose.covariance[0]设为0.0001（对应1cm精度），但实测编码器误差0.12m，协方差应为0.0144。

排查工具：

# 查看EKF输出协方差 ros2 topic echo /odometry/filtered --no-arr | grep -A 10 "covariance:" # 对比实测值

若输出协方差远大于实测标准差平方，说明EKF“不相信”该传感器，正在用其他传感器强行修正，导致过拟合。

修正策略：

• 重新实测各传感器噪声（静止IMU测yaw方差，直线行走测odom x方差）；
• 将协方差设为实测方差的1.2倍（留余量）；
• 临时禁用某传感器（注释imu0配置），确认误差是否回归正常，定位问题源。

5.4 “rviz2里小箭头消失”：TF发布失败的隐蔽陷阱

现象：/odometry/filtered话题有数据，但rviz2中不显示蓝色箭头。
日志特征：/diagnostics无报错，ros2 topic hz /odometry/filtered显示正常频率。

真相：EKF虽发布/odometry/filtered，但未发布odom→base_linkTF。常见原因：

• publish_tf: false（配置文件中误设）；
• base_link_frame与机器人URDF中<link name="...">不一致（如URDF写chassis，配置写base_link）；
• static_transform_publisher未启动，导致base_link→imu_link缺失，EKF内部TF lookup失败，连锁导致odom→base_link不发布。

快速诊断：

ros2 run tf2_tools view_frames # 检查TF树是否完整 ros2 topic list | grep tf # 确认/tf话题存在 ros2 topic echo /tf --