企业官网建设流程全解析

机器人导航学习历程里，全局路径规划解决的是“从A点到B点走哪条路”，而真正让机器人动起来、绕开突然冒出来的障碍物、稳稳停到目标点面前的，是local planner。这篇文章是系列第四篇，我把自己在DWA、TEB两种主流局部规划器上踩过的坑、调过的参数、从仿真搬到实物的完整过程整理出来，希望能帮正在搞机器人导航的朋友少走弯路。

1. 全局规划和局部规划，别再把分工搞混

很多刚接触导航的朋友最容易犯的错，就是以为有了全局路径规划就完事了，机器人会沿着那条规划出来的线一路走到底。实际根本不是这样。全局规划器拿到的是一张静态地图，它规划出的路径是“假设周围环境完全不变”的前提下算出来的。可真实世界里，过道上突然有人、墙角多了纸箱、桌子的位置被移动过，这些都没法提前写进地图里。

local planner干的事，就是在全局路径的引导下，只盯着传感器实时看到的那一小片区域，以十几赫兹甚至更高的频率，滚动地给机器人下发速度指令。它可能只“看”前方几米的局部代价地图，但正是这个“只看眼前”的家伙决定了机器人会不会撞墙、能不能拐过窄门、会不会在目标点前原地打转。

你可以把全局规划理解成手机地图给的路线，local planner则是你开车时的实时判断。地图告诉你“前方第三个路口右转”，但真正让你避开突然窜出来的电瓶车、在路边停车时一把倒进车位的，是你眼睛看到的实际情况和手脚的瞬时操作。没有这个“实时判断”，机器人就是盲人开车，哪怕手里拿着再精确的全局地图也没用。

1.1 从一次真实卡顿说起

我印象最深的一次，是在实验室走廊里给机器人导航。全局路径规划得好好的，一条直线从房间A到房间B，中间经过一扇门。结果机器人走到门框附近时，开始左右来回扭动，速度一下掉到几乎为零，然后突然急加速往前冲，差点撞上墙。

查了半天，问题就出在local planner上。门框在局部代价地图里被同时算成了左右两个障碍物，规划器在每个控制周期里反复权衡“从左绕还是从右绕”，打分上微小的波动就会导致选择来回切换，表现出来就是机器人在门口“抽搐”。这让我彻底明白，导航系统里真正考验功力的，往往是local planner的调参，而不是全局规划器的配置。

1.2 数据流和接口关系，先理顺再动手

在动手调参之前，我强烈建议先把move_base框架下的数据流捋一遍。简单来说是这样的：

• 传感器（激光雷达为主）发布/scan数据，同时里程计发布/odom，定位模块（通常是AMCL）发布机器人在地图中的位姿/amcl_pose。
• 这几个话题喂给move_base后，维护两张代价地图：global_costmap和local_costmap。
• 全局规划器基于全局代价地图算出一条路径，作为参考航线发布到move_base/GlobalPlanner相关话题。
• local planner订阅这条全局路径，结合局部代价地图上的实时障碍信息，以20Hz左右的频率计算速度指令，发布到/cmd_vel。
• 底盘驱动节点订阅/cmd_vel，控制电机转动。

这套链路里，local planner就是最下游的“大脑”。它接收的信息有一半是参考性的（全局路径），另一半是实时性的（局部代价地图），输出的却是直接作用于硬件的速度指令。这就意味着，上游任何一点的误差——雷达标定偏差、里程计漂移、定位抖动——都会在local planner这级被放大，反映到机器人实际运动轨迹上。

2. 主流 local planner 选型：DWA、TEB 和其他

ROS导航栈里常用的local planner有好几种，我实际深度用过的是DWA（Dynamic Window Approach）和TEB（Time Elastic Band）。这两种思路完全不同，选型时不能盲目跟风，得看你的机器人底盘类型、应用场景和算力资源。

2.1 DWA：原理简单、计算量小，适合入门

DWA的核心思想很直白：在每个控制周期里，根据机器人当前速度构造一个“动态窗口”——这个窗口内的速度组合（线速度v和角速度ω）都是机器人能在下一个周期内实际达到的。然后在这个窗口内采样若干组(v, ω)，对每一组模拟出一条短时间内的运动轨迹，最后用评分函数给每条轨迹打分，选得分最高的执行。

DWA的评分主要看三项：轨迹终点方向跟全局路径的贴合程度（路径贴合度）、轨迹终点朝向与目标点的夹角（目标朝向度）、轨迹是否会碰到障碍物（障碍物距离）。这三项分别对应三个权重参数：path_distance_bias、goal_distance_bias、occdist_scale。

DWA的优点非常明显：计算量小，在低配工控机上也能跑得很流畅；参数少，核心就十几个，入门阶段很容易上手；对差速驱动机器人特别友好，两轮差速和全向底盘的场景下表现稳定。缺点同样明显：它本质上是短视的“贪心算法”，只考虑接下来几秒的运动，遇到复杂地形（比如U形障碍、窄缝通行）容易陷入局部最优，表现就是机器人进退两难。

2.2 TEB：能倒车、会绕路，灵活但调参费劲

TEB的思路完全不一样。它把机器人从当前位置到目标点（或一段全局路径）之间的轨迹，想象成一根有弹性的带子。障碍物给这根带子施加“斥力”，目标点和路径末端施加“拉力”，时间最优性施加“收紧力”。每个控制周期，TEB都在优化这条带子的形状，让它在避开障碍物的同时尽量平滑、尽量快速。

TEB最大的能力优势是：支持倒车、支持阿克曼底盘的最小转弯半径约束、能够在路径被阻断时主动修改轨迹而不是死板地跟随全局路径。如果你的机器人是阿克曼转向（像汽车一样前轮转向），或者需要在窄小空间里反复腾挪，TEB几乎是首选。

但TEB的代价是参数爆炸。光move_base_params和TebLocalPlannerROS相关的可调参数就有四五十个，权重项包括障碍物权重、动态障碍物权重、时间权重、运动学前向驱动权重、加速度惩罚权重等等。调TEB就像调一台光学相机，拧任何一个旋钮都可能牵动全局效果，新手很容易陷入调一天都没调明白的困境。

2.3 其他方案：了解即可，按需选择

除了DWA和TEB，还有几个值得了解的方案：

• MPC（模型预测控制）：每个周期求解一个带约束的最优控制问题，效果最好但计算量也最大，通常需要配合较好的CPU才能在嵌入式平台上实时运行。如果做科研、追求极限控制精度，可以研究。
• Pure Pursuit（纯追踪）：最朴素的路径跟踪算法，不避障，只负责“沿着给定路径走”。常用于路径已经明确、动态障碍物很少的场景，比如仓储AGV的轨道跟踪。
• Follow the Gap（间距跟随）：原理是找传感器数据中最大的无障碍间隙，朝间隙中点走。适合极度追求响应速度的避障场景，但路径平滑性很差。

2.4 选型对比表，按场景对号入座

我个人给的建议是：如果是第一次做机器人导航，或者底盘是差速驱动，优先上DWA。先把DWA调明白，理解清楚local planner的思考逻辑，再换TEB深入了解参数之间的关系，会轻松得多。我见过太多人一上来就上TEB，结果被几十个参数搞得怀疑人生，反而连基础导航都没跑通。

3. local planner 的“眼睛”：局部代价地图

local planner到底靠什么感知障碍物？答案就是局部代价地图（local costmap）。很多人调local planner只盯着速度参数，却忽略了代价地图这层基础，导致调了半天还是撞墙。

3.1 三层机制：静态层、障碍层、膨胀层

ROS的costmap插件架构把地图信息分成了好几层，跟local planner直接相关的主要是三层：

静态层（Static Layer）：加载预先建好的静态地图，主要给全局代价地图用。local costmap里一般也会开启，但作用有限，因为局部实时性主要靠传感器层。

障碍层（Obstacle Layer）：实时接收激光雷达/深度相机数据，把传感器检测到的障碍物点投影到代价地图栅格上。这一层是关键，它决定了机器人“当下看到”的障碍物在哪。障碍层的更新频率直接决定了local planner对动态障碍物的响应速度。update_frequency和publish_frequency我一般分别设成5.0和3.0（单位Hz），太低了会漏掉快速移动的障碍物，太高了浪费CPU。

膨胀层（Inflation Layer）：把障碍物按照机器人半径进行向外膨胀，膨胀出的区域标记出“危险程度”。离障碍物越近，代价值越高。这一层的inflation_radius和cost_scaling_factor直接决定了机器人在离障碍物多远的距离开始“害怕”。

inflation_radius设置为机器人内切半径的2倍左右比较常见。cost_scaling_factor则是控制代价衰减的快慢：取值越小，代价衰减越慢，机器人越早开始避让，路径更安全但绕的路也更多；取值越大，机器人越敢贴着障碍物走，路径更紧凑但风险更高。

3.2 传感器接入和雷达安装位置

local planner的实时避障能力，完全取决于传感器数据的质量。我踩过的一个大坑是：激光雷达安装高度和安装位置没有跟机器人的footprint对齐。

激光雷达数据本身只是一个二维平面扫描。如果雷达安装位置跟规划时设定的机器人中心不重合，就会出现运动方向跟障碍物位置错位的情况——明明激光扫描到左边有障碍物，机器人却已经向左转过去了，雷达数据才更新到位。

正确的做法是，先量准雷达相对于机器人base_link的坐标偏移，在配置文件中通过laser_scan插件的frame_id和TF树关系准确描述。我建议把raytrace_footprint和footprint配置得跟真实底盘外形一致，特别是对于有轮子外凸、车头突出的机器人，如果只是简单用矩形包围盒，窄通道里很容易发生“雷达说能过，实际车身刮到”的情况。

3.3 膨胀半径、机器人半径和速度的三角关系

这里有一个容易忽略的联动关系：膨胀半径和机器人最大速度必须匹配。

原因很简单：local planner是周期性规划的，每个周期之间机器人还在运动。假设控制周期是0.2秒，机器人最大线速度是1m/s，那一个周期内机器人最多前进0.2米。如果膨胀半径只比障碍物外扩了0.1米，那机器人很可能在规划器“意识到”危险之前就已经贴上障碍物了。

我一般参照这个经验公式来设定：膨胀半径 ≥ 机器人半径 + 最大线速度 × 控制周期 × 1.5。预留1.5倍的裕量是为了给刹车和加速度留出缓冲。把这个关系理顺后再去调local planner，你会发现很多诡异的问题（比如为什么老是擦到墙角）不用调速度参数就解决了。

4. 实操：从仿真到实物的参数调试记录

这一节我把实际调参的过程原原本本写出来，先讲DWA再讲TEB，重点是每个参数背后的逻辑和调参的先后顺序。

4.1 DWA 参数逐项拆解，照着抄也能跑

下面是一份我调好的差速底盘DWA配置，底盘最大线速度1.0m/s，最大角速度1.5rad/s。放在这里当模板：

DWAPlannerROS: # 速度限制 max_vel_x: 0.8 # 最大前进线速度 m/s min_vel_x: -0.2 # 最小线速度（允许轻微后退） max_vel_y: 0.0 # 差速底盘没有y向速度 min_vel_y: 0.0 max_vel_trans: 0.8 # 最大平移速度 min_vel_trans: 0.05 # 最小平移速度，低于此速度停车 max_vel_theta: 1.2 # 最大旋转角速度 rad/s min_vel_theta: 0.3 # 最小旋转角速度，低于此值不旋转 acc_lim_x: 0.5 # x向加速度限制 m/s^2 acc_lim_y: 0.0 acc_lim_theta: 1.0 # 角加速度限制 rad/s^2 # 目标容差 xy_goal_tolerance: 0.15 # 到达目标点的xy距离容差 m yaw_goal_tolerance: 0.2 # 到达目标点的朝向角容差 rad latch_xy_goal_tolerance: true # 前瞻与仿真参数 sim_time: 2.0 # 轨迹模拟时长 s sim_granularity: 0.025 # 轨迹模拟步长 m vx_samples: 30 # 线速度采样数量 vy_samples: 0 vyth_samples: 40 # 角速度采样数量 # 评分权重 path_distance_bias: 32.0 # 贴合全局路径的权重 goal_distance_bias: 20.0 # 朝向目标点的权重 occdist_scale: 0.2 # 避障权重（越大越保守） heading_lookahead: 0.6 # 计算朝向打分时的前瞻距离 m oscillation_reset_dist: 0.05 # 防抖动重置距离 m

这里面几个参数的含义我详细解释一下：

sim_time是轨迹模拟的时长。它决定了规划器“往前看多久”。设太短（小于1.0），机器人只顾眼前，容易在障碍物附近急转弯；设太长（大于3.0），计算量增大，而且远期的轨迹跟实际偏差大。我实测2.0秒左右对室内机器人是个不错的平衡点。

acc_lim_x和acc_lim_theta是加速度限制，这两个参数不仅限制规划的加速度，还会影响实际速度的变化率。它们必须跟底盘驱动器的能力匹配：设大了，机器人起步刹车太猛；设小了，机器人反应迟钝，遇到突然出现的障碍物刹不住。我给的0.5m/s²和1.0rad/s²适用于大多数室内底盘，如果你用的是大型底盘，需要根据电机和减速箱的加速能力重新标定。

occdist_scale是最容易让人困惑的参数。它越大，机器人越远离障碍物，但路径会绕更远；它越小，机器人越敢贴边走，但容易蹭到障碍物边缘。我建议新手从0.1开始往上加，观察机器人过窄通道的表现。0.2是典型值，如果发现在宽阔场地里机器人也走得很“怂”，就是它偏大了。

4.2 调参顺序：先速度后权重，一步一步来

我刚学local planner时有个坏毛病：一上来就同时改五六个参数，结果出了问题根本不知道是哪一步改坏了。后来总结出一套相对靠谱的调参顺序：

第一步，先定速度上限和加速度限制。这些是物理约束，应该由底盘能力决定，不是调出来的。把max_vel_x先设成底盘标称最大速度的80%，加速度设成底盘能承受的中等值。这样保证后面调权重时，机器人有足够的“行动范围”来展示问题。

第二步，调sim_time和采样数。把sim_time从1.5到2.5之间试一遍，观察机器人过窄通道、拐直角弯时的表现。采样数不足时，速度空间覆盖不全，机器人会表现出“犹豫不决”——要么选不到合适的路径，要么轨迹很生硬。vx_samples30、vyth_samples40是我常用的起点。

第三步，调评分权重。先保证障碍物权重能有效避障（occdist_scale0.15到0.3），然后调path_distance_bias和goal_distance_bias的比例。这两个权重决定了一个关键行为：当局部路径跟全局路径发生冲突时，机器人是“忠于全局路线”还是“直奔目标”。比重越大越忠于全局路线，比重越大越急于朝向目标点（容易抄近路撞障碍物）。我常用的比例是path : goal = 1.6 : 1，这样既能保证机器人沿着全局路径走，又不会在目标点附近绕远。

第四步，跑真实场景微调。前面三步基本能在仿真里完成，但真实环境的雷达噪声、地面打滑会导致参数需要小范围回调。回调时每次只改一个参数，改动幅度不要超过原值的20%，跑一圈看效果再决定下一步。

4.3 TEB 关键参数调整记录

TEB的参数多，但核心其实是几组。我整理了一份调TEB时的重点参数记录：

速度与加速度组：max_vel_x（最大线速度）、max_vel_theta（最大角速度）、acc_lim_x、acc_lim_theta。这组参数跟DWA一样，是物理上限，按底盘能力设。

避障与膨胀组：min_obstacle_dist（离障碍物的最小距离，默认0.2，建议不小于机器人半径+0.05）、inflation_dist（障碍物的影响范围，即“多远就开始躲避”，默认0.6）、penalty_epsilon（惩罚系数，控制避障的“柔和度”，值越大越安全，路径越绕）。

权重组：weight_obstacle（障碍物权重，默认100）、weight_dynamic_obstacle（动态障碍物权重，默认50，如果环境里人多，这个要加大）、weight_goal（朝向目标点权重，默认1）、weight_time（时间最优权重，默认1，决定机器人有多“急躁”）。weight_time特别有意思：它越大，机器人越追求走快，路径越短越激进；设小一点，机器人更稳重。我一般先设0.8，跑一段时间再微调。

运动学组：min_turning_radius（最小转弯半径，阿克曼底盘必须设置）、footprint_model（明确机器人的轮廓模型，支持点、圆、矩形、多边形）。

调TEB的过程比较痛苦，因为权重之间的交互非常强。我的经验是：用默认参数起底，然后只调三个参数——min_obstacle_dist、inflation_dist、weight_obstacle——先把基础避障跑稳，再去动其他权重。如果一开始就同时调七八个权重，大概率会越调越乱。

4.4 从仿真转到实物，三个最容易出问题的地方

我在Gazebo仿真里把导航调到自认为完美后，信心满满地往实物机器人上一搬，结果立刻翻车。教训非常深刻：

第一个差异是雷达数据的噪声。仿真里激光雷达是理想传感器，数据平滑、精度高。真实雷达有测量噪声、有丢帧、有吸光材质造成的盲区。后果是局部代价地图里障碍物的边缘不稳定，local planner在同一个障碍物边缘反复犹豫。解决办法是我降低障碍层的obstacle_range（从5.0降到3.5），让更远距离的读数不参与代价计算，减少噪点干扰。

第二个差异是里程计精度。仿真里里程计几乎是真值，真实机器人的轮子打滑、编码器误差会让local planner“以为自己走过去了”，实际并没有。后果是机器人不停重复调整位置，甚至在目标点前转圈。解决办法是给机器人加陀螺仪融合里程计，或者用更准确的里程计发布源。

第三个差异是底盘的实际响应。仿真里的速度指令会被完美执行，真实底盘有惯性、有响应延迟。acc_lim_*设得太乐观时，真实机器人根本达不到规划器认为能到达的速度，导致规划轨迹跟实际轨迹严重偏差。我的建议是，实物调试时把仿真参数里的所有加速度限制降低30%，把最大速度降低20%，先跑一个保守版本，确认稳定后再慢慢放开。

5. 常见问题排查实录：照着排错能省两天时间

导航出问题的时候，新手最容易陷入“怀疑人生”的状态：改了这个参数那里又不行了。我把这一年多实际见到的local planner相关问题整理成速查表，按现象排查效率很高。

5.1 机器人原地旋转的深层原因

关于“原地旋转”这个高频问题，我再多说一句。它往往不是local planner一个环节的错，而是整条链路的问题：xy_goal_tolerance设得太小（比如小于定位精度），机器人到了目标点附近，AMCL认为位姿偏差超差，于是规划出旋转修正路径；修正完定位又更新，又超差，又旋转，形成死循环。

这种情况下，先检查定位模块的位姿协方差，再检查目标容差跟定位精度是否匹配。室内机器人定位精度一般在±5cm左右，xy_goal_tolerance设0.1以下就是在逼机器人走单摆。老老实实设0.15到0.2，绝大多数目标点抖动问题直接消失。

5.2 贴墙走的深层原因

如果机器人总是贴着墙边走，看着都吓人，问题多半不在local planner里，而在代价地图的膨胀参数上。inflation_radius设得比机器人半径还小的时候，算法会认为“贴着墙沿走收益最高”，因为它评分时更看重贴合全局路径而不是避障。

调试技巧：把局部代价地图的发布频率调高，用RViz实时查看膨胀层显示效果。直观确认“红色危险区域”是不是完全覆盖了机器人footprint的边缘。如果没有，就是膨胀半径参数的问题，先改这个再考虑调速度权重。

5.3 仿真转实物后频繁重规划

这个问题非常典型。仿真环境干净，雷达噪声小，全局路径一旦规划好，机器人沿着走就行。到了实物，雷达噪点导致的局部代价波动，会让local planner对“当前位置是否偏航”的判断高频跳动，于是频繁上报路径不可行，触发move_base的重新规划。

对策有两个方向。一是在TrajectoryPlannerROS或DWAPlannerROS里检查有没有“重规划触发差值”类参数，在move_base层面可通过planner_patience和conservative_reset_dist等参数，允许一定时长内规划失败不触发全局重规划。二是降低局部代价地图的obstacle_range，减少远处噪点的影响。实际调试中后者通常立竿见影。

6. 从导航到抓取：local planner 的质量决定下游一切

最近很火的机器人导航仿真抓取实物，本质上就是导航和机械臂操作的衔接问题。很多人以为导航只负责“把机器人运到机械臂能抓到的地方”，然后机械臂自己干活就行。这个理解太天真了。

6.1 停不准，抓取就全是白搭

机械臂的抓取，往往依赖机器人底座的精确停位。你规划好的机械臂轨迹，全部基于“机器人底座在某个精确位姿”的假设。可实际执行时，local planner到达目标点的误差可能有好几厘米，底座朝向也可能偏个几度。

更麻烦的是，如果local planner在目标点附近反复调整（就是我前面说的原地摆动的场景），机器人停稳时跟规划位置偏差更大，机械臂的逆解根本算不出有效的抓取位姿。

解决思路是在导航任务里把目标点拆成两步：第一步，导航到目标点前50cm的“预备点”；第二步，以较低速度精确靠近目标点并调整朝向。预备点用常规的DWA参数跑，精确靠近阶段可以临时降低速度上限、收紧目标容差，避免大范围调整，让机器人以一种“小心翼翼”的方式走完最后一截。

6.2 局部路径平滑度对抓取稳定性的影响

机械臂抓取时，如果底座还在左右晃动——哪怕只有几毫米——末端执行器的位置误差会被机械臂的“杠杆效应”放大。local planner输出的轨迹如果不够平滑，频繁加减速，机器人到达目标点后的残留抖动会很严重。

解决办法有两个层面的：在导航层面，适当调大weight_kinematics_forward_drive（TEB）或增加路径平滑相关的权重，让机器人“走得稳”；在系统层面，让机械臂的视觉伺服模块等机器人底座完全静止后再触发抓取，通过监测/cmd_vel和实际速度为零持续1秒钟以上来触发“已停稳”信号。

仿真里Gazebo的物理引擎对地面摩擦和惯量的模拟相对理想，实物抓取时底座晃动的幅度往往比仿真里大不少。我的经验是，在实物上做抓取时，导航速度上限只开仿真里的60%左右，并且一定要给机械臂的视觉识别留足稳定时间。

6.3 仿真和实物的联合调试心得

那一段把导航和抓取打通的日子，是我收获最大的一段。总结下来，仿真最大的价值在于帮我把整套流程的坐标系关系、话题通信、时序逻辑跑通。真正决定项目成败的，永远是实物联调后的那几轮微调。

具体来说，仿真里可以放心大胆地把local planner参数来回折腾，走极端值看看效果。但一旦决定上实物，我就用“备份-调参-回退”的方式：每次实调前把当前参数备份好，一次只调一个方向，跑完记录现象，不好就回退，好就继续往下试。这个方法虽然土，但比“一把梭”高效太多。

另外，一定要把仿真和实物的差异参数单独拆分出来管理。我习惯用一套参数文件加条件加载的方式，速度、加速度、膨胀半径这类受物理环境影响大的参数分别维护sim_params.yaml和real_params.yaml，避免每次切换环境时遗漏某个关键参数导致安全事故。

7. 最后再说两句实在话

local planner确实是整个导航系统里最让我“又爱又恨”的部分。爱的是它直观——调参数立刻能在轨迹上看到变化；恨的是它是一个高度耦合的系统，任何上游的问题都能在这里暴露出来。

我个人在实际操作中有两点体会最深。第一，遇到问题先看数据，再看参数。打开RViz把局部代价地图、全局路径、机器人的速度指令全部显示出来，观察个一两分钟往往就能定位问题，比闷头改参数快十倍。第二，参数不是越“跑得快”越好，而是要匹配你的硬件能力和场景需求。一台实验室里慢悠悠走得稳的机器人，比一个在走廊里能跑到1.5m/s却动不动撞墙的机器人强太多。

这个系列后续我还会写一写导航跟上层任务调度怎么衔接、多传感器融合定位的话题。如果你在调local planner时遇到这里没讲到的问题，建议先把本章的参数表挨个在自己机器人上试一遍，把每个参数的“手感”摸清楚——这比任何教程都有用。