机器狗这种东西听起来像是实验室里搞了三年还没出成果的课题但我可以负责任地说只要你把ROS这一套吃透四足平台的路径规划搭建起来速度其实比想象中快得多。这个项目我前前后后折腾了两个月从零开始写URDF、搭导航栈、调move_base参数最后在仿真和实体上都能稳定跑起来。今天把这套完整方案记录下来给准备入坑机器狗导航的朋友一条能直接踩的路。先说说这个项目到底做了什么。简单来说给一台四足机器狗装上激光雷达和深度相机在ROS环境下完成SLAM建图然后基于move_base框架实现自主路径规划导航。机器狗和普通轮式底盘最大的区别在于运动模型完全不同——四足可以原地转向、侧移但速度空间又受到步态切换、机身晃动等因素的强烈约束所以move_base的配置思路和轮式机器人有本质区别。这篇文章会从环境搭建开始全套走一遍适合有ROS基础、想上手四足平台导航的朋友参考。1. 整体设计思路与关键技术选型1.1 为什么是move_base而不是自研规划器路径规划这个领域算法论文一抓一大把A*、Dijkstra、RRT*、DWA、TEB每个单独拎出来都能写好几篇博士论文。但工程落地的第一原则从来不是算法有多花哨而是稳定性、可维护性和社区生态。move_base作为ROS导航栈的核心框架把全局规划、局部规划、代价地图、恢复行为全部模块化封装好了你只需要针对自己的平台特性去配置和替换对应插件完全不需要从零造轮子。选择move_base还有一层现实考量它几乎是整个ROS社区验证最充分的导航框架。无论是室内服务机器人、户外巡检机器人还是工业AGV都是基于这套框架跑的。你踩过的坑前人大概率都踩过遇到问题去issue区和论坛一搜基本都能找到解决方案。对于机器狗这种运动模型复杂的平台用成熟框架可以减少非常多隐性风险。1.2 机器狗运动模型对导航架构的影响这是整个项目里最容易踩坑的地方我特意放到前面说。四足机器狗的运动学模型和差速轮、全向轮都不一样它是有限全向的——理论上可以朝任意方向移动但实际运动约束极其复杂。具体来说机器狗在站立、行走、小跑、奔跑这几种步态下可达到的线速度、角速度、加速度包络完全不一样。走步态下最大线速度可能只有0.3 m/s小跑能到1.0 m/s但此时转向半径会急剧增大。更要命的是机身存在周期性的质心起伏和俯仰/横滚波动如果这个波动传给了激光雷达的点云数据代价地图的质量会直接崩掉。所以在架构设计上我做了两个关键决策第一在move_base之上增加一个步态感知调度层。这是一个独立的ROS节点订阅步态状态机的状态实时动态调整move_base的max_vel_x、max_vel_theta、min_vel_x等速度上限参数。比如机器狗正在用爬楼梯步态时导航速度上限就压到最低切换到小跑步态时再放开速度。第二在点云进入代价地图之前增加一个机身姿态补偿节点。用IMU数据对雷达点云做姿态校正消除机身周期性晃动带来的点云畸变。这一步对move_base的local costmap影响极大不做的话局部规划器会频繁误判障碍物位置导致急刹和绕路。# 步态感知调度核心逻辑伪代码 class GaitAwarePlanner: def __init__(self): self.gait_state stand self.speed_profile { stand: {max_vel_x: 0.0, max_vel_theta: 0.0}, walk: {max_vel_x: 0.3, max_vel_theta: 0.8}, trot: {max_vel_x: 0.8, max_vel_theta: 0.5}, bound: {max_vel_x: 1.2, max_vel_theta: 0.3}, } def update_speed_limits(self): profile self.speed_profile.get(self.gait_state) # 通过dynamic_reconfigure动态更新move_base参数 set_move_base_param(max_vel_x, profile[max_vel_x]) set_move_base_param(max_vel_theta, profile[max_vel_theta])1.3 传感器方案的取舍和布置传感器选型是导航系统里最影响下限的决策我可以把话说得难听一点传感器选得不对算法再强也白搭。激光雷达负责精度深度相机负责补盲区两者必须配合使用。激光雷达我用的是单线雷达16线以上的多线雷达对室内导航来说性能够用但算力开销太大单线雷达在2D代价地图场景下性价比最高。安装高度上有个讲究——机器狗的机身高度会随着步态变化雷达安装得太低会被腿部摆动遮挡太高又探测不到近地障碍物。实测下来雷达离地高度25-30cm比较合适既能避开腿部扫描干扰又能覆盖大部分地面障碍。深度相机的布置更多是为了补近处盲区。单线雷达在水平面扫描但机器狗前方的低矮障碍物、台阶边缘是扫不到的深度相机可以很好地把这块补上。我用的是Intel RealSense D435i部署在机身前部稍微向下倾斜通过depthimage_to_laserscan把深度图转成伪激光数据和雷达数据做融合后统一送进costmap。注意两个传感器之间的外参标定一定要做准不然融合出来的点云会出现重影。2. 环境搭建与ROS安装避坑指南2.1 操作系统和ROS版本的选择逻辑这个问题的标准答案不是哪个版本最新用哪个而是哪个版本生态最成熟用哪个。我这次用的是Ubuntu 20.04 ROS Noetic原因很简单Noetic是最后一个支持Python 2终止前主流Python 3的ROS 1发行版社区资源极其丰富几乎所有导航相关的库和插件都有预编译包。如果你用Ubuntu 22.04 ROS 2 Humble性能和功能确实更现代但大量老牌工具链还没完全迁移过来调试成本会高不少。当然ROS 2 Humble在工程上也有很多优势尤其是多机通信和实时性这些方面比ROS 1强太多。如果团队有长期积累的意向直接上手ROS 2也不算错。对纯学习目的或者做毕设项目的朋友我建议从Noetic入坑资料多、坑少、容易出成果。2.2 鱼香ROS一键安装到底靠不靠谱说到ROS安装肯定避不开鱼香ROS一键安装这个东西。我第一次听说这四个字还以为是开玩笑的自己试了之后发现它确实解决了一个真实痛点ROS安装的依赖地狱问题。手动安装ROS最折磨人的不是那几条命令而是apt源的配置、公钥更新、依赖包冲突。尤其在国内网络环境下ros.org官方源的速度和稳定性都比较一般有时候装到一半源挂了整个系统依赖就乱掉了。鱼香ROS一键安装脚本做的事情本质上就是把换源、装依赖、初始化rosdep这些步骤全部自动化了。我的实际体验是一条指令跑完基本能搞定90%的事。剩下的10%主要是rosdep update还有可能偶发失败这时候用脚本里带的rosdepc工具替代官方rosdep基本能通。这里插一句很多人卡在rosdep过不去其实不是技术问题就是网络问题用rosdepc或者自己配置好代理源就行。# 鱼香ROS一键安装日常最常用的一条 wget http://fishros.com/install -O fishros . fishros # 自动换源、自动装ROS # 安装完成后验证 source /opt/ros/noetic/setup.bash roscore提示虽然一键脚本很好用但强烈建议安装完ROS之后自己手动编译一遍几个核心包比如geometry2、navigation、gmapping。手动编译能帮你摸清楚依赖关系后面出问题排查起来会快很多。2.3 工作空间和依赖包的完整准备工作空间这个事看似简单但布局不合理后面重构成本很高。我建议按功能拆成三个独立的workspacerobot_ws放本体相关的包URDF、传感器驱动、步态控制接口nav_ws放导航相关的包map_server、amcl、move_base配置、路径规划插件sim_ws放仿真相关的包gazebo模型、仿真环境。三个工作空间用source叠加的方式加载调试任何一个模块都不会影响到其他模块。划重点这种方式比单一大工作空间清爽太多了。依赖包方面除了ROS自带的navigation全套move_base、amcl、map_server、costmap_2d我额外安装了以下几个必装包teb_local_planner局部规划器对机器狗这种非完整约束运动模型更友好robot_localization多传感器融合里程计的关键工具后面细讲rtabmap_ros可以作为建图备选方案应对大场景漂移问题joint_state_publisher和robot_state_publisher机器人状态发布调试URDF必需3. 机器狗模型构建与仿真验证3.1 从零写四足URDF模型的心得URDF是ROS里描述机器人本体的XML文件四足模型的难点不在语法而在坐标系定义和关节组织。很多新手会忽略一个关键点base_link坐标系必须在机身几何中心而不是默认原点。如果base_link不在质心位置后面所有传感器的外参标定、TF树都会乱掉。我建议先画一个简化模型跑通流程四条腿各3个关节髋关节横滚、髋关节俯仰、膝关节俯仰每条腿对应一个腿编号FL、FR、RL、RR。这里有个很实用的技巧用xacro宏定义一条腿然后通过参数化配置四次实例化代码量能减少70%。!-- 腿部的xacro宏定义节选 -- xacro:macro nameleg paramsprefix side joint name${prefix}_hip_roll_joint typerevolute parent linkbase_link/ child link${prefix}_hip_link/ origin xyz${side * 0.15} 0 0.1 rpy0 0 0/ axis xyz1 0 0/ limit lower-0.5 upper0.5 effort100 velocity5/ /joint !-- 髋关节俯仰和膝关节俯仰类似 -- /xacro:macro模型建完之后务必用urdf_to_graphiz查看TF树结构。常见问题包括link之间的父子关系搞反、joint的xyz和rpy设置错误导致运动学算不出解这些在仿真里会把机器人拧成麻花。3.2 在Gazebo中搭建测试场地仿真的核心目的是验证算法不是炫技。所以我强烈推荐先用最朴素的测试环境一个平面加几块障碍物。很多人一上来就搭一个操场级别的仿真场景结果跑都跑不动没必要。Gazebo的世界模型我用一个长宽各20m的平面放了几堵墙和几个箱子。关键在于给雷达和相机模型加上真实噪声——Gaussian noise的sigma值设置在0.01这个数量级。完全没有噪声的仿真数据会让算法过度自信真机上稍微有点传感器噪声就直接崩。仿真跑通move_base之后别急着上真机先做两个压力测试一个是在arena地形加斜坡和楼梯另一个是加入动态障碍物可以用gazebo的actor模型模拟行人。动态障碍物测试非常重要很多静态环境跑得好好的config文件一遇动态障碍物就露馅。4. move_base全面配置与路径规划深度集成4.1 move_base架构拆解两个代价地图与两种规划器move_base的全部工作可以概括为一个不停接收目标点的服务器action server在两张地图上分别做全局路径规划和局部运动规划再交给底盘执行。全局代价地图global_costmap负责全局长距离路径规划局部代价地图local_costmap负责短距离实时避障两者可以有不同的分辨率、不同的更新频率、不同的传感器数据源。规划器方面move_base默认自带两个全局规划器global_planner提供A*、Dijkstra、最佳路径等可选算法局部规划器base_local_planner默认是DWA动态窗口法对机器狗来说默认DWA最大问题在于它把机器人当作完整的圆处理不考虑机器狗的多方向运动能力和狭小空间转身需求。所以我果断换成TEBTimed Elastic Band做局部规划器。TEB可以把机器狗的运动学约束以凸优化的形式写进去无论是差速约束还是类全向约束都能比较自然地表达。4.2 全局路径规划A*算法vs其它选择全局规划器里那几个算法很多人选不好其实根本没得选——我明确告诉你A*在大部分场景下是最优解。Dijkstra能保证全局最优解但由于没有启发项实时搜索区域是全向扩张的效率低下RRT虽然在高维空间表现好但在2D栅格地图上属于杀鸡用牛刀A兼顾完备性和效率对移动机器人导航来说就是标准答案。global_planner插件里有个关键参数是use_dijkstra默认是true代表使用Dijkstra算法。把它改成falseA就生效了。实测下来在大地图上A能快30%-50%路径质量几乎没差别。# global_planner参数配置 GlobalPlanner: use_dijkstra: false # 使用A*算法 use_grid_path: false # 用梯度下降路径比grid_path平滑 use_quadratic: true # 二次插值路径更平滑 visualize_potential: true # 可视化势场调试的时候很有用 old_navfn_behavior: false # 不要用旧版navfn的行为注意A*规划出的路径是网格化的折线直接给到底盘执行会一顿一顿的必须做路径平滑处理。我一般用use_quadratic加TEB局部规划的优化双管齐下解决。4.3 局部路径规划TEB参数调优的完整思路TEB是局部规划器里折腾最久的部分它的本质是通过时变弹性带把路径当可伸缩的带子来优化同时考虑时间最优性和障碍物约束。对机器狗来说它的最大优势是能直接表达全向移动朝向约束这些复杂运动学限制。TEB的参数非常多但真正决定行为的核心参数就几个# teb_local_planner核心参数 TebLocalPlannerROS: odom_topic: odom/filtered # 融合后的里程计 map_frame: map min_obstacle_dist: 0.20 # 离障碍物最小距离机器狗要适当放大 inflation_dist: 0.3 # 障碍物膨胀距离 max_vel_x: 0.8 # 最大线速度 max_vel_x_backwards: 0.3 # 最大倒车速度别设太大 max_vel_theta: 0.6 # 最大角速度 acc_lim_x: 0.5 # 线加速度限制 acc_lim_theta: 0.5 # 角加速度限制 penalty_epsilon: 0.1 weight_obstacle: 100 # 避障权重 weight_dynamic_obstacle: 10 # 动态障碍物权重调参过程中最重要的原则是先保安全再求效率。我一开始把max_vel_x调到1.0 m/s结果机器狗在仿真里各种撞墙。后来把速度降下来min_obstacle_dist适当放大到0.2m避障成功率一下就上来了。TEB调参是在效率和安全之间的舞蹈每一次调整都要在仿真里反复验证别指望一次到位。4.4 局部代价地图与全局代价地图的参数联动两个costmap的参数配置决定了整个导航系统的感知范围和精度联动关系处理不好容易出现全局路径规划好了、局部却以为撞墙这种尴尬局面。核心参数在costmap_common_params.yaml里统一管理我会点出几个机器狗场景下必须注意的参数# costmap_common_params.yaml obstacle_range: 3.0 # 障碍物被计入地图的最大距离比雷达探测距离小一点 raytrace_range: 3.5 # 自由空间清除的最大距离必须大于obstacle_range footprint: [[-0.25, -0.15], [-0.25, 0.15], [0.25, 0.15], [0.25, -0.15]] # 机器狗身体的真实轮廓 inflation_radius: 0.4 # 代价膨胀半径必须大于机器人最大半径 observation_sources: laser_scan_sensor point_cloud_sensor laser_scan_sensor: sensor_frame: laser_frame data_type: LaserScan topic: scan marking: true clearing: true point_cloud_sensor: sensor_frame: camera_depth_frame data_type: PointCloud2 topic: camera/depth/points marking: true clearing: truefootprint这里最坑。默认是0.2m半径的圆形这对轮式小车没问题。但机器狗身体是矩形结构且四条腿在运动时会向四周伸展footprint必须用多边形精确描述。我一开始没注意导致costmap里机器人周围的膨胀区域过小实际走过去腿撞到障碍物了。硬件上我把四条腿加装上防撞软胶之后脚部在摆动中有了一定的容错范围这个算是机械层面的辅助方案。inflation_radius也有讲究——太小路径会贴着墙走太大在狭窄区域根本规划不出路径。我建议先用0.4m起步根据实际场景的通道宽度微调。如果测试环境里有0.5m宽的走廊膨胀半径就得压到0.3m以下。4.5 机器狗特有问题的深度集成优化说完通用配置再讲几处针对机器狗平台的深度集成工作。这些东西ROS文档里基本没有完全靠实测踩坑总结。问题一机身姿态波动对局部代价地图的污染。机器狗在行走时机身的俯仰和横滚是周期性变化的这会导致激光雷达扫描到地面的点产生畸变。如果你把这些畸变点直接送进costmap局部地图会周期性出现假障碍物TEB会频繁急刹甚至绕路。解决方案是在数据链路中加上imu姿态补偿# robot_localization配置核心融合IMU和轮式里程计 ekf_filter_node: frequency: 50.0 sensor_timeout: 0.1 two_d_mode: true # 虽然机器狗是3D运动但导航只在2D平面 odom0: odom/wheel imu0: imu/data imu0_config: [false, false, false, true, true, false, # 使用IMU的roll和pitch不用yaw false, false, false]我使用robot_localization里的EKF做传感器融合输出一个姿态补偿后的odom/filtered。这个odom稳定性极好本地规划器的输入干净了很多。注意IMU在yaw方向不要随便融合yaw方向最好用轮式里程计来积分防止漂移。问题二步态切换时速度空间突变导致TEB规划震荡。机器狗从walk切到trot的瞬间运动能力上限突增如果TEB的参数还停留在walk对应的状态它会以为我很慢而做出过于保守的规划。反之从trot降回walk时TEB会按高速状态规划路径然后因为超出速度约束而频繁重规划。这对应的问题就是第一节提到的步态感知调度层在ROS里用dynamic_reconfigure动态修改TEB参数即可这块要做成闭环。# dynamic_reconfigure动态修改TEB参数 import rospy from dynamic_reconfigure.client import Client teb_client Client(move_base/TebLocalPlannerROS, timeout5) def update_teb_for_gait(gait_name): if gait_name walk: teb_client.update_configuration({max_vel_x: 0.3, max_vel_theta: 0.8}) elif gait_name trot: teb_client.update_configuration({max_vel_x: 0.8, max_vel_theta: 0.5}) elif gait_name stand: teb_client.update_configuration({max_vel_x: 0.0, max_vel_theta: 0.0})问题三四足机器人原地转向时的避障盲区。机器狗在执行原地转向动作具体来说是以机身中心为轴做原地旋转时四条腿会在身体周围甩动作摆动。此时如果有障碍物落在腿部摆动范围内它可能扫到腿或者被腿挡住。我做了两件事解决这个问题一是规划时禁止在狭窄区域原地转向具体是通过TEB的weight_kinematics_forward_drive参数让转弯半径偏好不为0二是在底层步态控制器里加一个碰撞检测暂停——代价地图检测到腿部摆动空间被占用时步态控制器会暂停转向改成先平移再转向。5. 定位、建图与导航的完整链路打通5.1 AMCL定位机器狗场景下的配置技巧AMCL是ROS里最经典的自适应蒙特卡洛定位算法在二维环境对单线雷达的定位效果相当好。机器狗场景下配置AMCL有几个坑要专门处理。第一个坑是初始位姿。四足机器人开机时关节会重新归零这时里程计的坐标系可能有一个很大的初始偏差。所以我习惯在机器狗开机后先执行一次自动校准流程机器狗站定用IMU确认水平姿态然后通过AMCL的initialpose话题发布当前位置估计也可以使用global_localization模式做一次全局重定位把不确定性摊开到整个地图上。第二个坑是粒子数量和更新频率。机器狗运动时的姿态波动比轮式机器人剧烈如果粒子数太少定位容易跟丢。我这里把AMCL的最小粒子数设在1000最大2000更新频率设为10Hz。同时把激光雷达的max_beams设为60控制运算量不至于太高。# amcl配置关键参数 amcl: min_particles: 1000 max_particles: 2000 update_min_d: 0.1 # 移动0.1m触发重采样 update_min_a: 0.1 # 旋转0.1rad触发重采样 laser_model_type: likelihood_field # 对结构复杂环境更鲁棒 laser_max_range: 10.0 transform_tolerance: 0.5 # TF延迟容忍机器狗必须设大一点第三个坑是transform_tolerance。四足机器人的TF树比轮式机器人多了很多关节变换IMU和里程计融合也有延迟如果容忍时间设太短AMCL会频繁报无法获得变换的错误。设到0.5秒也就是容忍500ms的TF延迟基本就稳了。5.2 SLAM建图实战gmapping还是Cartographer建图方案我在gmapping和Cartographer之间反复横跳了很久最后结论是室内小场景用gmapping完全够用室外或者大面积场景用Cartographer更稳。GMapping基于粒子滤波在小场景1000平米以内精度高、计算量低参数调节直观非常适合新手快速跑通。Cartographer的优势在于加入了回环检测和图优化长走廊、大环线场景下不容易漂移。代价就是配置复杂、计算量大机器狗自带的工控机跑Cartographer会比较吃力。我的建议是先跑通gmapping把整个导航链路验证完再考虑切换Cartographer做更复杂场景的建图。别一上来就上Cartographer数据都没玩明白就去调闭环检测参数纯属浪费时间。# 启动建图gmapping roslaunch dog_navigation gmapping.launch # 启动机器狗底盘 roslaunch dog_bringup robot_base.launch # 手动遥控机器狗走遍场景 rosrun teleop_twist_keyboard teleop_twist_keyboard.py # 建图完成保存 rosrun map_server map_saver -f map_dog_workshop建图时有个专项注意事项机器狗行走时要把步态频率调低一点。步态频率越高机身的周期性振动幅度越大会直接压低雷达数据的精度。我用walk步态、速度0.2m/s的条件建图效果相当理想走廊轮廓基本没有毛刺。5.3 TF树设计从map到base_link的全链路TF树是ROS里最核心的坐标系管理体系跑到定位、避障、规划的任何环节TF树一断整条链路就崩了。机器狗的TF树设计如下map → odom → base_link → base_laser_link ↓ base_imu_link ↓ FL_hip → FL_thigh → FL_calf FR_hip → FR_thigh → FR_calf RL_hip → RL_thigh → RL_calf RR_hip → RR_thigh → RR_calf注意odom到base_link之间的变换是由robot_localization发布base_link到各个关节之间的变换由robot_state_publisher根据关节角度计算发布map到odom之间的变换由AMCL发布。这三段必须各司其职任何一段崩了都会导致导航系统直接罢工。我最常遇到的问题是多个节点同时发布同一个TF变换。特别是刚开始调试的时候robot_state_publisher和步态控制程序都可能发布base_link到关节的变换两个来源打架TF树就乱了。排查方法也很简单用tf2_echo逐段查看变换是否存在、是否连续、频率是否正常。# 查看TF树是否正常 rosrun rqt_tf_tree rqt_tf_tree # 逐段检查关键变换 rosrun tf2_ros tf2_echo map odom rosrun tf2_ros tf2_echo odom base_link rosrun tf2_ros tf2_echo base_link base_laser_link6. 常见问题与排查技巧实录6.1 机器狗导航问题排查速查表这段时间测试下来我把最典型的七类问题整理成了一张速查表可以直接对照排查问题现象可能原因排查思路解决方案move_base无法启动costmap参数里footprint不合法查看move_base日志确认footprint数据修正footprint多边形顶点顺序需逆时针全局路径规划迟迟不出路径costmap膨胀半径过大或障碍物范围设置错误在RViz里可视化costmap看障碍物是否正常注入调整inflation_radius、obstacle_range和raytrace_range局部规划器频繁急刹或震荡TEB参数与平台运动能力不匹配录制bag回放查看cmd_vel曲线降低max_vel_x、增大min_obstacle_dist导航过程定位漂移AMCL粒子数不足或TF延迟过大用RViz看粒子分布用tf2_echo检查TF延迟增加粒子数增大transform_tolerance机器狗走路撞到腿附近的障碍footprint设置比实际机身小测量机器狗腿部伸展范围更新footprint扩大footprint在机械层增加腿部防撞软胶转弯时避障失败TEB转弯约束不当查看TEB可视化检查转向半径调整weight_kinematics_forward_drive控制原地转向偏好建图回环漂移严重走了太大场景gmapping回环不足用Cartographer做对比测图大场景切换Cartographer或将场景拆分成多段建图再拼接传感器融合后位姿突变EKF权重配置不当录制bag回放对比odom和filtered调整IMU和里程计的融合权重合理配置mask6.2 排查实战一个经常复发的幽灵障碍物问题这里特别要分享一个我排查了很久的诡异问题。现象是这样的机器狗行驶在看似空无一物的平坦路面上TEB局部规划器却频繁急停RViz里局部costmap上出现了一个不断闪动的幽灵障碍物位置不固定忽隐忽现。排查顺序是这样的先看激光雷达话题原始点云在某个特定角度确实有噪点把噪点投影到2D栅格上发现它出现在雷达正上方的天花板上——是一个高处的悬挂物被雷达扫到了但我的代价地图配置的是2D理论上应该忽略这种点其实不是的如果雷达安装得有一定仰角高处物体反射的激光会投影到2D平面上形成假障碍物解决方案有两个方向 一是调整雷达安装角度让它尽量水平或轻微下倾 二是在costmap的传感器数据预处理阶段加一个高度过滤只保留某个高度范围内的点云参与2D代价地图更新。用pointcloud_to_laserscan节点传递数据时可以顺手配置一个高度区间过滤器这样把高于机器人本体安全余量的点全过滤掉。# pointcloud_to_laserscan高度过滤示例 pointcloud_to_laserscan: min_height: 0.05 # 地面以上5cm max_height: 0.45 # 机器人最高点以上留10cm余量 angle_min: -1.57 angle_max: 1.57这个问题对轮式机器人同样适用只要你的雷达不是绝对水平安装就必须做这个过滤。经验之谈90%的幽灵障碍物问题都是传感器高度过滤没做干净导致的。6.3 实战心得仿真到真机的三大关最后分享一下从Gazebo仿真顺利迁移到真机的过程中必然要过的三道关卡希望可以帮你绕开这些必经的坑。**第一关传感器噪声的差异。**仿真里的高斯噪声和真实激光雷达的混合像素噪声、多路径效应相比简直就是幼儿园级别。真机第一次测试时我做好了频繁急停的心理准备但实际遇到的情况比预想中严重得多——TEB在真机上直接进入蠕动模式走一步停三秒。解决方案是先在真实环境下重新标定雷达再适当增大costmap的obstacle_range和raytrace_range的差值让自由空间清除更彻底。**第二关执行器的延迟和惯性。**仿真里的速度指令能瞬间到达底盘但真机有通信延迟和电机响应时间。这里必须引入预测控制的概念让move_base在下指令时预留出反应时间。具体做法是把TEB的dt_ref调大增加规划时间步长同时把max_vel_x在真机上再降20%起步等稳了再逐步放开。**第三关关节回零与坐标系初始化。**每次开机机器狗的关节角度不一定回到同一个机械零位这会导致URDF模型和真实位姿对不上进而带崩TF树。我用了一个强制流程每次启动导航前先执行关节回零程序确认所有关节达到预期角度再放开控制权。这个习惯帮我免掉了很多无缘无故定位飘没了的问题。这块系统我做了大概两个月从零到稳定运行最大的体会是**机器狗导航比轮式机器人难但难不在算法而在工程集成。**move_base的框架足够成熟真正需要花时间的是理解机器狗的运动学约束、做好传感器数据预处理、调好参数并且反复测试。希望在读这篇的朋友能在四足平台的导航路上少走弯路早日跑出稳定的规划效果。
