ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

别用DWB为难阿克曼底盘:MPPI切换与调参实录

别用DWB为难阿克曼底盘:MPPI切换与调参实录 这个标题我想了很久核心就是一句话别用DWB去为难阿克曼底盘。事情是这样的。之前给一台阿克曼转向的小车做导航底盘是前轮转向、后轮驱动的标准结构控制器用的是Navigation2默认的DWB。结果在走廊里走直线还好一到拐弯就露馅——要么原地打转一样往外飘要么明明路很宽它非要画一个特别大的弧线好不容易转过去车头方向又偏了。折腾了快一个星期最后把控制器从DWB换成了MPPI问题一下子清爽了很多。这篇东西就是给同样在Ubuntu 22.04 ROS 2 Humble环境下搞阿克曼小车导航的朋友写的。我会把为什么换、怎么换、换了之后参数怎么调以及我在实际调试中踩过的坑全部摊开讲一遍。适合已经跑通Nav2基础导航、想进一步优化阿克曼底盘控制效果的人参考也适合正准备给阿克曼小车选控制器的同学提前避雷。1. 为什么从DWB切换到MPPI1.1 DWB控制器的“差速基因”与阿克曼底盘的冲突DWB全称是Dynamic Window Based Local Planner它是DWA的升级版。DWA的思路是在速度空间里采样线速度v、角速度ω用代价函数评估每个采样轨迹选一条最划算的。DWB把里面的评价函数拆成了更细的“critics”比如避障、路径对齐、目标点对齐等每个critic有权重灵活性比DWA高不少。问题在于DWB的规划空间本质上是按差速底盘设计的。差速底盘可以原地转、可以横着绕速度空间是个矩形——v和ω基本解耦。但阿克曼底盘不一样前轮转角有限转弯半径有下限车不能原地掉头而且转弯时线速度和角速度是耦合的ω v * tan(δ) / Lδ是前轮转角L是轴距。你看这个关系式就明白了阿克曼车在低速大转角的时候ω很大但一旦速度提上去同样的转角对应的ω会变得非常夸张。DWB采样的时候根本不理解这种耦合它在一堆“不可能实现”的轨迹里选选出来的命令要么超出转向限制要么前后矛盾。表现出来就是转弯时速度忽快忽慢像新手司机猛打方向。为了转个小弯车会先减速到极低再猛打方向导致轨迹很难看。狭窄空间里DWB倾向于“凑一凑”挪过去但阿克曼根本凑不了。还有一个更烦的问题DWB的“旋转到目标朝向”这类critic默认允许原地旋转。对于差速车原地转是常规操作对于阿克曼车原地旋转根本执行不了于是车会一直尝试旋转然后被costmap的膨胀层卡住进入“抖动—停止—再抖动”的死循环。我第一次遇到这个现象时一度以为是里程计标定出了问题后来才意识到是控制器模型不匹配。1.2 MPPI控制器到底怎么想问题的MPPI全称Model Predictive Path Integral control翻译过来是“模型预测路径积分控制”。它和MPC模型预测控制是同一个思想家族但算法实现路径不一样。传统MPC比如很多论文里用的是通过优化求解器在每一帧解一个带约束的非线性优化问题找一组最优控制序列。优点是精度高缺点是计算量大、对模型精度敏感而且在阿克曼这种非线性强、约束多的系统上求解器很容易陷入局部最优或者干脆无解。MPPI绕开了这个麻烦。它不做显式优化而是用蒙特卡洛采样。每一帧算法以当前状态为起点随机采样一大批未来控制序列比如1000条每条都用机器人运动模型往前推一段轨迹比如推56步然后用代价函数给每条轨迹打分最后把这些控制序列按“轨迹质量”加权平均得到这一帧的命令。听起来是不是有点像粒子滤波对思路确实接近价值加权平均替代了梯度下降。正因为MPPI是“采样—评估—加权”的结构它对运动模型的适应能力极强。你只要把模型换成阿克曼运动学采样空间也换成“线速度前轮转角”它天然就能理解什么东西可实现、什么东西不可实现。而且它不需要显式求雅可比矩阵对非光滑代价函数也扛得住这在真实机器人上非常实用。Nav2从Humble版本开始把MPPI作为独立控制器集成进来了而且原生支持Ackermann运动模型这就是我下定决心换掉DWB的原因。2. Ubuntu 22.04上的运行环境准备2.1 系统基础apt源、显卡驱动与ROS 2 Humble正式开始之前先确认你的基础环境是干净的。我用的是Ubuntu 22.04.3 LTSROS 2发行版是Humble Hawksbill。如果你还在用ROS 1 Noetic或者Ubuntu 20.04下面的配置路径会有些差异最好先统一到这套组合上来。第一步是apt源。默认的Ubuntu官方源在国内拉取速度很慢ROS 2包动不动几百MB等起来很痛苦。我在装系统后干的第一件事就是把源换成清华镜像或阿里云镜像二选一即可。操作方式很简单修改/etc/apt/sources.list里的源地址然后sudo apt update。这里提醒一句换源后一定要确认universe、restricted、multiverse这些组件都保留了否则装ROS依赖的时候会缺包。ROS 2 Humble的安装其实很机械添加ROS 2 apt源和密钥sudo apt install ros-humble-desktop装桌面版全套把/opt/ros/humble/setup.bashsource进bashrc。装完之后检查ros2 --version能输出带Humble字样的版本信息就算成功。至于显卡驱动做纯小车导航其实不太用得上GPU但如果你打算在Gazebo或Isaac Sim里跑阿克曼模型仿真显卡驱动就很重要了。Ubuntu 22.04装NVIDIA驱动我推荐用ubuntu-drivers devices查看推荐版本然后sudo apt install nvidia-driver-XXX安装。装完重启nvidia-smi能看到GPU信息就行。千万别自己去官网下载runfile硬装遇到过太多因为DKMS版本不匹配导致开机黑屏的情况了在22.04上用apt源装是最稳的。2.2 安装Navigation2与MPPI组件环境就绪后接下来是Nav2。我建议直接用二进制包省时省力sudo apt install ros-humble-nav2-bringup ros-humble-nav2-mppi-controller注意这个nav2-mppi-controller包它并不一定随着nav2-bringup自动装上至少在Humble版本里我遇到过缺失的情况。如果启动时提示找不到nav2_mppi_controller::MPPIController插件十有八九就是没装这个包。为了确认MPPI插件已经被正确注册可以看看安装后的插件描述文件ros2 pkg list | grep mppi ls /opt/ros/humble/share/nav2_mppi_controller/正常的输出里应该有mppi_controller.xml之类的插件描述文件。没有的话排查一下包是否安装完整或者考虑用源码编译。另外如果你打算在仿真里验证建议装好Gazebo和ackermann-steering-controllersudo apt install ros-humble-gazebo-ros-pkgs ros-humble-ackermann-steering-controllerackermann-steering-controller是ROS 2官方提供的阿克曼底盘控制器插件后面会把MPPI输出的Twist消息转换成真实的前轮转角这个环节是阿克曼车落地的关键后面我会专门讲。3. MPPI核心参数与阿克曼适配原理3.1 采样、评估、加权三步看懂MPPI在动手改配置之前先把MPPI的几个核心参数搞懂否则后面调参就是瞎试。采样与控制序列。每一帧MPPI一次采样batch_size条控制序列每条序列有time_steps步相邻两步的时间间隔是model_dt。所以一条轨迹预测的时间总长 time_steps * model_dt。这是一个需要重点平衡的量预测时间太短车只看得到眼前一米转弯容易犹豫预测时间太长计算量大而且远处的costmap更新滞后反而误导规划。我的经验是阿克曼车预测总时长控制在3~5秒比较合适。噪声标准差。MPPI采样的控制序列不是完全随机的而是在“上一帧最优解附近”加高斯噪声。噪声的标准差就是vx_std、vy_std、wz_std这些参数。它们决定了控制器探索的范围。标准差太小算法只会围绕当前命令小幅波动遇到障碍物反应迟钝标准差太大大量采样落在墙角或障碍物里浪费时间。代价加权。每条采样轨迹都会算一个总代价代价越低说明轨迹越好。MPPI给每条轨迹的权重和代价呈指数关系权重正比于 exp(-(cost - min_cost) / temperature)。temperature在这里相当于softmax温度——越小越“贪心”几乎只认最优轨迹越大越“平均”会把次优轨迹也混合进来。阿克曼车如果temperature设太小容易沿着一条局部最优轨迹僵住设太大轨迹平滑但保守甚至对障碍物不敏感。gamma是折扣因子用来给轨迹中不同时间点的代价加权。gamma越小越看重近期的代价对远期风险不敏感gamma太大远期代价占比高车会为了躲一个远处的障碍提前绕大圈。阿克曼车因为转弯半径大我一般让gamma在0.01到0.02之间避免远期过度敏感。3.2 阿克曼模型专属约束MPPI最吸引我的一点是它支持直接把运动学模型设成Ackermann。motion_model: Ackermann一旦启用Ackermann模型MPPI不再采样侧向速度vy阿克曼车本来就不能横移而是采样线速度vx和转向角steering。然后根据阿克曼几何关系把转向角折算成角速度ω。这里有一个容易被忽略的机制阿克曼模型下的输出不是直接给前轮转角而是给cmd_vel中的线速度vx和角速度ω。底盘端还需要一个转换节点把ω和vx换算成前轮转角并下发到转向电机。换算公式就是阿克曼运动学δ arctan(ω * L / vx)其中L是轴距。vx接近0的时候这个公式会出问题所以工程上要在底盘驱动里做保护速度过低时前轮回正不允许原地转向。Model设成Ackermann之后需要配上阿克曼的约束参数。Nav2 MPPI里这些参数放在一个独立子块里ackermann_constraints: min_turning_r: 0.2 max_turning_r: 3.0 track_width: 0.4min_turning_r是允许的最小转弯半径这个值要参考底盘实测值。如果设得太大车转不过小弯设得太小——比如设成0.1但车的最小转弯半径其实是0.8——算法会规划出超越机械极限的轨迹实车执行时就会出现打滑、转向电机堵转。所以这个参数一定要实测不要拍脑袋填。max_turning_r是最大转弯半径主要影响直线判定设一个比场地半径大的值就行。track_width是轮距主要用来做轮胎打滑检测和转向角近似修正如果你的底盘不是高速竞技场景给个近似值影响不大。3.3 Cost批评器怎么搭配MPPI的代价函数是一组critic的加权和。Nav2里常用的几个critic有TrajectoryCritic对整条轨迹的代价做积分相当于基准项。ObstacleCritic检测轨迹是否穿越障碍物看的是costmap代价。PathAlignCritic评估轨迹与全局路径的横向偏差偏差越大代价越高。PathAngleCritic评估轨迹方向与全局路径方向的夹角角偏越大代价越高。GoalCritic评估轨迹终点与目标点的距离。GoalAngleCritic评估轨迹终点朝向与目标朝向的偏差。PreferForwardCritic鼓励前进、惩罚倒车。阿克曼车因为不能横移、转弯半径大路径对齐和方向对齐这两个critic极其重要。如果PathAlignCritic权重太高车会拼命往全局路径上“挤”但因为阿克曼车转弯需要空间结果就是左右震荡如果PathAngleCritic权重太高车会在每个路径点上都试图马上对准方向导致转弯前提前减速、转弯后回正困难。一个相对合理的起点是Obstacle PathAngle PathAlign Goal PreferForward。先保证碰撞安全再保证方向正确然后才是路径贴合。碰撞权重一定是所有critic里最高的否则车会在“沿路径走”和“别撞墙”之间摇摆而摇摆对于阿克曼车来说往往意味着冲出路径。4. 从DWB到MPPI的配置实操4.1 编写MPPI控制器yamlNav2的启动流程通常通过一个总参数文件把所有节点参数传进去。如果你用nav2_bringup的标准launch这个文件往往叫nav2_params.yaml里面按节点名分段。我们要做的就是新增MPPI控制器的配置块。我直接给一份我在阿克曼小车上用下来的配置骨架controller_server: ros__parameters: use_sim_time: true controller_frequency: 20.0 min_x_velocity_threshold: 0.001 min_y_velocity_threshold: 0.001 min_theta_velocity_threshold: 0.001 failure_tolerance: 0.3 progress_checker_plugin: progress_checker goal_checker_plugins: [general_goal_checker] controller_plugins: [FollowPath] progress_checker: plugin: nav2_controller::SimpleProgressChecker required_movement_radius: 0.5 movement_time_allowance: 10.0 general_goal_checker: stateful: true plugin: nav2_controller::SimpleGoalChecker xy_goal_tolerance: 0.25 yaw_goal_tolerance: 0.3 FollowPath: plugin: nav2_mppi_controller::MPPIController time_steps: 48 model_dt: 0.1 batch_size: 1000 vx_std: 0.25 vy_std: 0.05 wz_std: 0.4 vx_min: -0.35 vx_max: 1.0 wz_min: -1.0 wz_max: 1.0 temperature: 0.3 gamma: 0.015 motion_model: Ackermann ackermann_constraints: min_turning_r: 0.5 max_turning_r: 8.0 track_width: 0.4 critics: [TrajectoryCritic, ObstacleCritic, PathAlignCritic, PathAngleCritic, GoalCritic, GoalAngleCritic, PreferForwardCritic] TrajectoryCritic: enabled: true cost_power: 1 cost_weight: 4.0 ObstacleCritic: enabled: true cost_power: 1 cost_weight: 5.0 PathAlignCritic: enabled: true cost_power: 1 cost_weight: 2.0 max_path_occupancy_ratio: 0.05 trajectory_point_step: 4 threshold_to_consider: 0.5 offset_from_furthest: 20 PathAngleCritic: enabled: true cost_power: 1 cost_weight: 3.0 max_angle_to_furthest: 1.0 mode: 0 GoalCritic: enabled: true cost_power: 1 cost_weight: 1.5 threshold_to_consider: 1.0 GoalAngleCritic: enabled: true cost_power: 1 cost_weight: 1.0 threshold_to_consider: 1.5 PreferForwardCritic: enabled: true cost_power: 1 cost_weight: 1.0 threshold_to_consider: 0.5这里几个关键点说明一下。vx_min我设成负值允许一定倒车阿克曼车在窄通道里有时需要倒一把再转完全禁止倒车会很难办。wz_min和wz_max是输出角速度的限幅根据最大转向角和速度上限换算。controller_frequency我用的20Hz对于机载电脑性能一般的小车MPPI的batch_size1000在20Hz下比较吃紧如果CPU占用太高可以先降到15Hz或者把batch_size降到800。critics列表顺序没有严格约束但建议把TrajectoryCritic放在第一个它是最基础的代价累积项。4.2 修改Nav2总参数文件有了MPPI配置块之后需要把原来DWB的配置块整体替换掉。DWB的配置块长这样这是我原来用的FollowPath: plugin: dwb_core::DWBLocalPlanner ... critics: [BaseObstacle, ObstacleFootprint, PathAlign, GoalAlign, PathDist, GoalDist, RotateToGoal] BaseObstacle: plugin: dwb_critics::BaseObstacle ...切到MPPI后必须把plugin改成nav2_mppi_controller::MPPIController并把DWB的critics全部删掉或注释掉。这里是我第一次切换时踩的坑我只改了plugin名字没有清理critics列表结果启动报了一堆“plugin not found”因为DWB的critic插件和MPPI的critic插件完全是两套东西。另外要注意controller_server节点下的min_x_velocity_threshold这类参数。MPPI本身有自己的vx_min、vx_max而min_x_velocity_threshold是controller_server用来判断车辆是否“停住”的阈值如果设置太大比如超过了MPPI的允许最低速度就会出现在目标点附近车明明还在动、但controller判定已经到达目标的情况。我建议设置成0.001越小越好。还有failure_tolerance这个参数它表示controller_server多久没有收到有效控制命令就触发失败。MPPI启动初期如果有一次采样全落在不可行区域可能短暂无输出failure_tolerance设得太小会被误判为控制器失效。0.3秒是我觉得比较稳的值。4.3 启动与可视化验证配置改完后启动流程和之前完全一样还是ros2 launch nav2_bringup bringup_launch.py map:/path/to/map.yaml params_file:/path/to/nav2_params.yaml如果你想在Gazebo仿真里先验证可以再加上use_sim_time:true并且确保你的机器人URDF里配置了阿克曼底盘模型和ackermann_steering_controller。启动后第一件确认的事是检查controller_server是否真的加载了MPPI插件ros2 param get /controller_server FollowPath.plugin如果输出nav2_mppi_controller::MPPIController说明插件加载成功。然后你可以打开rviz2加载Nav2的默认配置文件观察全局路径和局部规划。有一点我特别想强调rviz里看到的局部轨迹曲线并不等于实际底盘走的轨迹。MPPI会可视化它采样出的最优轨迹通常是一条平滑曲线但阿克曼底盘的执行结果取决于你底盘驱动里“转角→速度”的转换是否准确。如果实际走出来的弧线和rviz里展示的差别很大先查底盘运动学参数而不是急着调MPPI。5. 实测调参让阿克曼小车从会走到走得好5.1 第一版参数我当时的测试场景是一个约10米见方的室内场地中间放了几个纸箱当障碍物地面是环氧树脂地坪轮胎抓地力中等。阿克曼小车轴距0.55米前轮最大转向角30度最小转弯半径约1.1米。按前面的骨架配置启动后第一版参数基本能跑但问题很多路径跟踪时车经常向右偏感觉像“追不上”规划路径。到纸箱附近时车减速特别猛然后缓慢地蹭过去通过效率极低。从静止起步时车会犹豫一两秒才开始动好像不知道该往哪个方向打方向。这些问题都符合MPPI参数没调好的典型表现。我逐步做了修改。5.2 场景实测与调整记录测试一直道启动。现象起步迟缓车身左右微摆像在“找方向”。分析阿克曼车起步时MPPI采样空间里vx很小、转向很大大量轨迹在低速下对着左右大角度转这些轨迹的代价差异不明显加权平均后转向角被“平均”成了一个接近0的值车自然就犹豫了。处理把temperature从0.3降到0.15让最优轨迹的权重更突出同时把wz_std从0.4适当提高到0.5让采样更充分覆盖大转角空间。改完后起步明显果断了很多车身微摆也减轻了。测试二中速弯道。现象过弯时车会先大幅减速然后以很低的速度“挪”过弯弯后加速很慢。分析阿克曼车过弯时为了满足横向加速度约束MPPI会在过弯前减速。但如果ObstacleCritic权重过高算法会在过弯时过分保守认为任何一点靠近障碍物都不可接受于是贴着costmap的膨胀边缘慢慢蹭。处理把ObstacleCritic的cost_weight从5.0降到4.0同时把PathAlignCritic从2.0提到2.5让路径跟随更果断一些。另外我注意到costmap的膨胀半径对MPPI影响也很大如果膨胀半径设置成0.3米而车宽0.4米车会认为几乎没有可通行空间这个问题后面在避坑章节细说。测试三窄直角弯。现象车总是转不过去来回打方向最后被controller_server判定失败。分析这是阿克曼车的经典困境——最小转弯半径1.1米但直角弯的有效转弯空间只有不到1米。MPPI确实在尝试采样大转角轨迹但min_turning_r设的0.5米超出了机械极限导致采样出来的小半径轨迹执行不了。处理把min_turning_r从0.5改成1.0更加贴近真实机械极限。很多人以为设小一点能让车“更灵活”但实际是自欺欺人算法以为能转过去底盘执行不了最后就是来回折腾。改成1.0后MPPI会老老实实规划一个“借道”的大弧线虽然路径看起来不够紧凑但至少能一遍过。测试四目标点停靠。现象车到目标点附近后对不准总差20~30度的朝向然后反复前进后退修正。分析这是GoalAngleCritic和GoalCritic的权重匹配问题。如果目标点朝向的代价权重太低车到位置就“觉得够了”不会再调整朝向如果权重太高车会在目标点附近反复划弧线找方向。处理把GoalAngleCritic的threshold_to_consider从1.5米缩到1.0米让车在1米外不关心朝向进到1米内才开始调整。同时把GoalAngleCritic的cost_weight从1.0提到1.8。这样车在靠近目标时会自然减速对准方向也不会在远处就开始转身。5.3 参数组合心得几轮测试下来我总结出几个对阿克曼底盘特别重要的调参心得第一min_turning_r 一定要按实测来不能为了“通过性”乱填。MPPI本身足够聪明你给它真实约束它会自己规划出可行轨迹给它假约束它只会反复生成不可执行轨迹。第二PreferForwardCritic 的权重不要设太高。阿克曼车倒车确实别扭但在狭窄空间里小幅倒车加重新规划往往比硬转效率高。如果你的场地比较宽大这个critic设个0.5~1.0就够了如果场地很窄可以提到2.0以上。第三temperature 和 vx_std 是“犹豫症”的开关。车犹豫不定先降 temperature车决策太激进先降 vx_std。这两个参数的组合效果远比单独调某一项明显。第四别忽略 costmap 膨胀半径。MPPI避障看的是costmap代价值膨胀半径设得太大等于把有效通行空间人为缩小了阿克曼这种需要“走大弯”的车特别吃亏。我最后把膨胀半径从0.3改到了0.15通过率提升非常明显。6. 常见问题排查与避坑技巧6.1 典型故障速查表我按照时间顺序把切换和使用MPPI过程中遇到的高频问题整理成表方便你直接对照。现象可能原因解决方向启动时提示plugin not found没装nav2_mppi_controller或有DWB critic残留安装MPPI包清理配置里的DWB criticsrviz里没有MPPI轨迹可视化MPPI参数块没被加载或rviz配置里没订阅对应topicros2 param get检查插件确认controller_server启动了MPPI起步犹豫、车身微摆temperature过高最优轨迹权重被稀释降低temperature适当增大wz_std到障碍物附近减速太猛ObstacleCritic权重过高或膨胀半径过大降低ObstacleCritic权重调小costmap膨胀半径过弯转不过去min_turning_r参数设置过小与实际机械极限不符实测最小转弯半径拉大min_turning_r目标点附近反复修正朝向GoalAngleCritic权重高、threshold_to_consider偏小调整goal朝向相关权重和触发距离车速不稳定、一冲一冲vx_std偏大采样轨迹速度方差过大降低vx_std或给cmd_vel输出加一阶低通直线行驶时蛇形摆动PathAlignCritic和PathAngleCritic权重失衡增加PathAngleCritic权重控制系统纠偏幅度车在目标点附近停不下来min_x_velocity_threshold设置过大把threshold调小到0.001计算延迟高控制频率上不去batch_size过大或机载电脑性能不足减小batch_size降低controller_frequency6.2 几条独家避坑经验这里分享几条网上很少讲清楚、但我实际验证过的经验。第一阿克曼模型下“倒车”和“前进”的转向逻辑是反的。前进时方向盘右打车头右转倒车时方向盘右打车尾却往左甩。MPPI的Ackermann模型内部会处理这个逻辑但前提是底盘端接收到vx为负值、ω为正值时要正确地把它换算成“倒车左转”的前轮转角。很多自制的阿克曼底盘驱动只实现了前进时的换算倒车时直接把ω当成了前进转向角结果车一倒车就乱甩。这个坑特别隐蔽因为前进时一切正常直到你需要倒车避障才会发现。第二MPPI在狭窄通道里“抄近路”的问题。有几次测试MPPI规划的局部路径没有完全沿着全局路径走而是选择了一条看起来更直的“捷径”结果差点撞上路缘。这是因为PathAlignCritic权重不够加上全局路径本身在窄通道里被膨胀层压得变形。我的办法是把PathAlignCritic的max_path_occupancy_ratio设小并适当提高权重。这个参数的意思是允许路径上有多少比例的占用网格设成0.05可以保证MPPI不会为了抄近路而穿过本来就不该去的地方。第三MPPI必须配合好的全局路径。MPPI再强也只是局部控制器它的预测时域最多看几秒。如果全局路径在阿克曼车无法通过的地方比如贴着墙规划了一条半径0.3米的弧线局部控制器再调也是白搭。我后来在全局规划器里把转弯半径约束也考虑了大致做法是在costmap里对“最小转弯半径内的走不通区域”做额外膨胀从源头保证全局路径就是阿克曼可执行的。第四注意use_sim_time一致性。如果你在Gazebo仿真里跑use_sim_time必须同时出现在controller_server和local_costmap等相关节点里有个地方漏了表现就是MPPI的轨迹一直在变、小车像喝醉了一样。这是Nav2里面最常见、也最容易被忽略的“低级错误”。第五用ros2 topic echo /cmd_vel观察输出。调参时不要只盯着rviz多看看cmd_vel的实际值。阿克曼车正常情况下线速度vx和角速度ω之间应该有明确的几何关系ω vx * tan(δ) / L。如果你发现某个时刻vx很小但ω很大说明MPPI在尝试一个不可行转向这时候应该回去检查min_turning_r或者转向角的限幅。这个判断方法调参时特别好用。6.3 一点个人体会从DWB折腾到MPPI前后用了两个多星期的晚上。回头看最大的感受是“选对控制器模型比调参数重要得多”。DWB本身是好控制器在差速底盘上表现不俗但硬套在阿克曼底盘上再好的参数也弥补不了模型不匹配的硬伤。MPPI原理上更复杂计算量也更大但它对运动模型的适应能力让我愿意为它买单。如果你也正在给阿克曼小车做导航我的建议是先别急着堆参数花点时间把底盘的最小转弯半径、轴距、最大转向角这些物理参数都实测一遍填进MPPI的ackermann_constraints里再去微调critic权重。基础数据对了后面的调参事半功倍基础数据错了后面怎么调都是空中楼阁。最后再分享一个小技巧每次改动参数后先跑一段最简单的直线和U型弯确认基础行为没问题再加大场景复杂度。这样能快速定位是参数问题还是场景问题不至于在复杂环境中被一堆问题搞得焦头烂额。希望这篇下来能帮你少走点弯路让你的阿克曼小车早日在走廊里丝滑地跑起来。
返回列表