做自动驾驶控制的人绕不开纵向控制这道坎。油门、刹车、车速这三个量之间的关系看似简单但实际跑起来就会发现很难让车辆精准地跟住一个目标速度尤其是在仿真环境和真实车辆之间来回切换的时候。我最早接触这个方向时也是从PID入手的选型上直接用了CARLA仿真器加ROS2这套组合。当时为什么这么选以及整个链路搭起来之后踩过哪些坑我觉得比单纯讲PID公式更有价值所以这篇内容就按“实战”的节奏来写从整体思路到环境搭建再到算法实现和调参过程尽量把每一处细节都讲透。先说结论纵向控制的核心就是让车辆的实际车速跟随期望车速而PID在这个场景下依然是最高效、最稳妥的起点。虽然现在很多人一上来就提LQR、MPC但我觉得PID过了这么多年还没被淘汰是因为它有不可替代的优势——结构简单、参数直观、调试方便而且对算力要求极低。你在CARLA里做仿真验证时先把PID这套逻辑吃透后面再切到更复杂的控制器也会有清晰的对比基准。1. 项目整体设计与技术选型思路1.1 为什么选CARLA而非其他仿真器市面上能做自动驾驶仿真的工具不少比如Gazebo、AirSim、BeamNG.tech还有自动驾驶行业里常见的SUMO、LGSVL等。但CARLA在“车辆动力学真实性”和“传感器仿真完整性”这两个维度上做得特别均衡。它是基于UE4引擎开发的车辆模型带有轮胎、悬挂、空气阻力这些物理属性跑起来的动态响应比较接近真实情况。这一点对于纵向控制调试非常重要因为如果你的车辆模型过于理想化控制器的参数和结论都很难迁移到真车上。另外一点是CARLA的接口设计比较友好。它原生提供了Python API也维护了面向ROS2的桥接包所以在ROS2里订阅车辆状态、发布控制指令都很顺畅。相比之下Gazebo侧重机器人场景对自动驾驶车辆底盘的建模不够细致而AirSim更偏向飞行器和四旋翼车辆的动力学模型不如CARLA直接。所以我个人的判断是做车辆纵向控制仿真CARLA是当前体验最好的选择。1.2 ROS2在这套方案里的角色定位ROS2在这套方案里扮演的是“通信中枢”的角色。CARLA通过自身服务端跑仿真但所有节点的协作、话题的流转、参数的管理都要交给ROS2来做。先说为什么要用ROS2而不是ROS1首先是社区方向ROS1已经停止维护新项目没有必要再向旧框架迁移其次是ROS2的分布式架构在多机协同、DDS通信方面天然更适合车路协同这类场景再者CARLA官方维护的桥接包已经全面转向ROS2踩坑的博客和示例代码也更丰富。我实际用的是ROS2 Humble版本搭配Ubuntu 22.04。这套组合在CARLA 0.9.15上验证过稳定性还不错。如果你用的是ROS2 Foxy或者Galactic也可以跑但建议避免直接用最新版ROS2 Jazzy来跑CARLA因为兼容性还需要观察。如果你对ROS2的基础概念还不够熟先花一两个小时把节点、话题、服务、参数这几个核心概念过一遍再回来做控制会顺很多。1.3 PID与纵向控制的匹配关系PID控制器的本质是“误差驱动的反馈控制”。放在纵向控制场景里就是不断检测期望车速和实际车速之间的差值然后把这个差值映射成油门或刹车的输出量。这个任务的难点在于车辆是一个带有较大惯性的被控对象从你踩下油门到车速真正变化中间存在明显的延迟而PID的三个参数恰好就是用来处理这种延迟和动态特性的。P项看的是当前误差解决“现在差多少”的问题I项累积历史误差解决“长期偏差”的问题尤其是上坡或者风阻这类持续存在的干扰D项预判误差变化趋势解决“冲过头”的问题。三者的配合逻辑和开车时的肌肉记忆很像你看到车速慢了就会多踩一点油门看到车速接近目标了就松一点看到要超了就提前抬脚这就是一套天然的PID反应。我特意选了增量式PID作为实现方式因为它在输出端天然带有抗积分饱和的特性而且适合嵌入到定时控制周期里。增量式输出的不是绝对控制量而是相对于上一次输出的增量所以控制量变化平稳不容易出现大幅抖动。2. 环境搭建与CARLA-ROS2联调实战2.1 Ubuntu 22.04下的ROS2 Humble安装要点ROS2的安装本身不难但有些细节会影响后面的联调。不要直接用apt源里可能过期的版本建议按照官方文档来操作。先把软件源和公钥配置好然后分步安装。这里有个容易忽略的地方ROS2 Humble的默认RMW实现是FastDDS而CARLA桥接包在工作时会持续高频收发消息FastDDS对系统网络栈的配置比较敏感。如果你发现消息偶发断流优先检查防火墙和共享内存配置这个我在后面问题排查章节会展开。装完ROS2后记得把环境脚本写入~/.bashrc。我自己习惯用zsh所以写的是~/.zshrc。如果你同时装了多个版本用source /opt/ros/humble/setup.bash时一定要写对路径公众号和博客里因为写错路径导致环境冲突的案例实在太多了。接着装一些实用工具比如colcon用于构建工作空间rqt和rviz2用于可视化和调试。这些工具后续调试PID时非常有用尤其是rqt_plot可以实时画出期望车速和实际车速的曲线调参效率比只看日志高出一大截。2.2 CARLA版本选型与安装细节CARLA的版本更新节奏比较快但并不是越新越好。截至我写这篇内容时CARLA 0.9.15和0.9.16是稳定性较好、社区资料也较充足的版本。0.9.15对应的是CARLA官方ROS2桥接包发布比较完整的版本所以我建议新手从0.9.15开始等流程完全跑通之后再尝试更高版本。安装CARLA有两种常用方式。第一种是下载预编译的压缩包解压即可用第二种是从源码编译但耗时很长一般不建议为了跑个纵向控制去编译源码。注意CARLA本体要求GPU支持比较新的图形接口显卡驱动一定要更新到较新版本否则启动后会黑屏或者报渲染设备错误。启动CARLA服务端时有几个参数值得记住。-quality-levelLow可以让渲染负载降低提升仿真的运行速度-fps20可以限制仿真帧率让控制周期更稳定-windowed配合小分辨率窗口适合在没有专显的机器上调试。我用的是./CarlaUE4.sh -quality-levelLow -fps20 -windowed启动的实测下来CPU占用和显卡占用都比较可控。2.3 使用CARLA官方ROS2桥接包打通链路启动仿真器之后接下来要做的事情就是把CARLA里的车辆状态以ROS2消息的形式送出来同时把我们算好的控制指令送回去。这一步通过CARLA官方维护的ros_bridge完成。建议直接用官方提供的carla_ros_bridge工作空间。把它下载下来后用colcon build构建注意所有依赖都要提前装好。构建完成后先启动桥接节点source /opt/ros/humble/setup.bash source ~/carla-ros-bridge/install/setup.bash ros2 launch carla_ros_bridge carla_ros_bridge.launch.py启动成功后你要做两件关键的事一是确认话题列表里面有/carla/ego_vehicle/vehicle_status这个话题会定期发布车辆的速度、位置等信息二是确认有/carla/ego_vehicle/vehicle_control_cmd或者类似的控制指令话题用于发布我们计算出来的油门、刹车和转向值。这时候还要注意CARLA里有个“自动驾驶模式”的开关。打开它之后CARLA自带的自动驾驶AI会接管车辆控制你发的控制指令就不生效了。所以做自己的纵向控制实验时一定要关闭这个自动驾驶模式用set_autopilot(False)命令或者在spawn_vehicle的时候就明确指定不启用自动驾驶。2.4 首次联调让车辆动起来的完整流程为了让后面的PID控制有对象我们得先在CARLA里生成一辆自动驾驶车辆。这里我写了一个Python脚本放在CARLA的Python API目录下运行。脚本的核心逻辑是连接CARLA服务端、选择地图、生成车辆、关闭自动驾驶、设置初始位置和朝向。生成车辆后桥接节点会自动把车辆信息同步到ROS2侧。此时你可以先用键盘控制脚本或者手动发布一个简单的控制指令验证链路是否完整。我习惯先发布一个“恒定油门0.3”的消息观察车辆能否加速再试着发布一个“刹车0.5”的消息观察减速是否正常。如果这两步都正常说明总线链路没有问题接下来就可以接上PID控制器了。这里还要提一句CARLA里的车速单位是m/s而不少从整车开发转过来的朋友习惯看km/h换算关系是1 m/s 3.6 km/h。后续调PID参数时建议统一使用m/s否则计算控制误差的时候非常容易乱。3. 纵向控制算法原理与PID实现3.1 纵向控制的完整闭环逻辑你把车辆看作一个被控对象输入是油门踏板开度、刹车踏板开度输出是实际车速。期望车速则是由上层路径规划模块给出来的刚才我们为了简化可以手动设定一个随时间变化的目标速度比如先让它从0加速到10 m/s再减速到5 m/s。闭环控制的每一步是这样的读取当前车速、计算当前误差、调用PID控制器、得到控制输出、把输出映射成油门刹车指令、发布到CARLA、等待下一个控制周期。这个过程以固定的频率循环执行一般控制周期在20到50Hz之间。我用的是20Hz即50毫秒跑一次控制逻辑这对于CARLA仿真和PID而言都足够平滑也不至于让CPU负载过高。值得强调的是PID输出的是一个抽象控制量需要你自己设计“油门刹车切换逻辑”和“映射关系”。比如PID输出为0到1之间的正数就对应油门开度PID输出为负数就取绝对值对应刹车开度。同时设置一定的控制死区比如误差在±0.1 m/s以内就不做调整否则车辆会由于细小的噪声反复震动。3.2 增量式PID与位置式PID的选型分析位置式PID输出的是完整的控制量也就是直接计算当前应该给多大油门。它的好处是直观但是积分项一旦累积过头输出就会饱和恢复很慢。增量式PID输出的是控制量的增量也就是“这次比上次多踩一点”或者“这次比上次松一点”。由于计算的是差值即使误差很大输出变化也是渐进的抗积分饱和能力天然更强。我在这个项目里选择的实现方式是增量式PID代码如下。这里给出的版本是通用的离散化形式误差量是期望速度减去实际速度class IncrementalPID: def __init__(self, kp, ki, kd, dt): self.kp kp self.ki ki self.kd kd self.dt dt self.prev_error 0.0 self.error_acc 0.0 self.output 0.0 def reset(self): self.prev_error 0.0 self.error_acc 0.0 self.output 0.0 def compute(self, target, current): error target - current # 增量式PID输出 delta_output self.kp * (error - self.prev_error) \ self.ki * error * self.dt \ self.kd * (error - 2 * self.prev_error self.last_prev_error) / self.dt # 更新历史 self.last_prev_error self.prev_error self.prev_error error self.output delta_output return self.output注意代码里有个容易被忽略的点就是D项的微分部分。位置式PID的微分是kd * (error - prev_error) / dt但增量式PID因为计算的是输出的增量所以微分项里会出现当前误差、上一时刻误差和上上时刻误差的三项差分。这个推导细节很多博客都没有讲清楚如果你写位置式的D项直接套到增量式里D参数的作用方向会完全错误。不过实际调试中很多场景下D项用处不大因为仿真的速度反馈相对平滑而且D项对噪声敏感。我在这个项目里前期把kd设为0等P和I调稳了之后再根据超调情况决定要不要加D。这符合大多数工程实践。3.3 油门刹车切换与下限控制PID输出的范围我做了归一化处理限制在-1到1之间。正数代表油门需求负数代表刹车需求。但是直接把0到1映射成油门开度0%到100%会有问题——实际车辆在低速甚至静止时油门开度到10%以上就会有明显加速而在高速巡航时2%的油门就能保持车速。所以单纯线性映射不够线性需要加一个“最小输出阈值”。我在项目里设置了一个THROTTLE_DEADZONE默认0.02。当PID输出绝对值小于0.02时视为无控制需求油门和刹车都置零。当输出大于0.02时油门开度等于输出值乘以0.6也就是把PID输出的60%作为油门比例当输出小于-0.02时刹车开度等于输出绝对值乘以0.4。这样设置的好处是PID在正常控制范围内的输出变化不至于让油门和刹车太敏感。刹车部分还有一个逻辑就是当车辆速度已经低于0.3 m/s而PID仍输出刹车时直接置零防止仿真器出现原地抖动的现象。这个在仿真里可能看不太出危害但你在后续做真实车辆移植时这种处理能有效防止刹车泵频繁动作。3.4 控制节点ROS2代码结构解析ROS2节点的实现我用了Python的rclpy虽然执行效率不如C版本但控制周期只有20HzPython完全可以满足而且调试方便。核心的逻辑是订阅期望速度话题和目标速度话题然后在一个定时器回调函数里完成控制计算。节点里订阅的话题有两个。第一个是/carla/ego_vehicle/vehicle_status从中读取车辆当前速度第二个是/planning/target_speed这是上层规划发来的目标速度话题实际项目里会由规划模块发布。在仿真阶段我自己写了一个简单的速度规划发布节点让目标速度在一段时间内随时间变化用以测试PID的跟随效果。发布的话题是/carla/ego_vehicle/vehicle_control_cmd消息类型是carla_msgs.msg.CarlaEgoVehicleControl需要填充的字段包括throttle、brake、steering、hand_brake等。注意reverse字段如果你的目标速度是正向的倒车标志要置False否则车辆会一边踩油门一边挂倒挡原地不走。定时器的频率我用10Hz试过也用过50Hz。10Hz时控制本身也能跑得起来但油门输出会明显有阶梯感车辆速度曲线不平滑50Hz时平滑度好很多但对桥接消息的处理压力大了一点偶尔会出现消息积压。最终权衡20Hz是合适的。4. 参数整定方法与调参实操全流程4.1 从零到一的PID参数整定步骤PID参数整定最忌讳的是一上来就三个参数同时调。我的方法是分三步走。第一步把ki和kd都设成0只保留kp。从一个较小的kp0.3开始发布一个阶跃目标比如从静止直接设目标速度为8 m/s然后观察实际车速的响应曲线。如果车速上升太慢适当增大kp如果车速来回震荡减小kp。这一步的目标是找到一个不震荡但能比较快逼近目标速度的P值。第二步加I项。在P能保证基本跟踪的情况下会发现车辆速度总是差一点到不了目标值或者稳定后有较大的稳态误差。这时逐步增加ki每次增加的量可以控制在0.02到0.05之间观察稳态误差是否被消除。注意积分项作用明显滞后增加后要等十几秒才能看到效果不要急。第三步根据超调表现决定是否加D。如果车辆明显超过目标速度再回拉而且回拉过程很长可以尝试少量增加kd。但是前面也说了速度反馈本身就比较平滑D项能起到的效果有限如果加了D之后反而出现高频抖动就果断去掉。4.2 参数标定过程中使用的可视化工具我最常用的调试工具是rqt_plot。它可以直接订阅话题绘制实时曲线不需要写任何代码。具体操作如下source /opt/ros/humble/setup.bash ros2 run rqt_plot rqt_plot /carla/ego_vehicle/vehicle_status /planning/target_speed在rqt_plot界面里选择target_speed曲线设为红色vehicle_status设为绿色叠加显示后就能直观看出误差大小和响应形状。我还习惯再加一个/control/pid_output话题也就是PID节点发布的控制量输出这样能一眼看出油门刹车切换是否频繁、输出是否饱和。如果你的机器性能允许也可以使用plotjuggler它功能更强可以离线回放数据或者导出CSV做后处理。但是起步阶段rqt_plot完全够用而且零配置。4.3 调参过程中的典型速度响应曲线解读我在实调过程中遇到的第一种曲线是“慢爬坡型”。车速从0慢慢接近目标值但很久都到不了目标而且越来越慢地逼近最终的稳态误差显著。这说明P项偏小同时I项缺失。处理办法是增大kp并开始加ki。第二种曲线是“过山车型”。车速迅速冲过目标然后掉头往下再冲上去反复震荡好几个周期。这往往是P项太大导致的第一步就要把kp减小。如果减小之后仍然还有周期性过冲就要检查是不是控制周期太长比如用10Hz控制车辆在每个50毫秒内走的路程更多对控制的响应产生了额外延迟。第三种曲线是“起步抖动型”。车辆在低于1 m/s的区间内油门和刹车指令频繁切换车辆一冲一顿。原因是PID输出的正负切换太频繁。解决方案有两个一是增大死区范围二是把刹车侧输出进行滞回处理也就是刹车侧的启动阈值比油门侧更高一些。4.4 期望速度规划与测试场景设计调参不能只测匀速跟车必须覆盖加速、减速、巡航、停车再起步这几个基本场景。我设计了三组测试速度规划。第一组是阶跃加速测试目标速度0时刻从0跳到8 m/s保持30秒。这用于测试P和I的响应速度、超调量。第二组是正弦波动测试目标速度在5到12 m/s之间做正弦变化周期30秒用于测试系统的跟踪能力和动态响应。第三组是停车再起步测试目标速度先走到8 m/s然后降到0保持5秒再升到8 m/s测试刹车停稳和重启的稳定性。你需要特别注意第三组场景因为它对PID参数的要求跟巡航不一样。车辆在低速时动力学非线性和底盘静摩擦力对控制影响更大PID参数如果用高速工况标定的在低速时可能会变得迟钝。5. 常见问题与排查技巧实录5.1 CARLA和ROS2桥接后消息不稳定的处理这类问题在联调过程中出现频率非常高。表现是carla_ros_bridge启动后控制指令发布出去但车辆没有反应过了一段时间才有响应或者偶尔丢帧。第一反应检查RMW的通信配置。FastDDS默认用共享内存如果你的系统内存不足或者设置不当消息分发给阻塞。可以在/etc/sysctl.conf里调整共享内存大小或者直接切换到CycloneDDS试试两者切换后桥接稳定性会有所区别。切换的方法很简单安装ros-humble-rmw-cyclonedds-cpp然后在环境变量里设置RMW_IMPLEMENTATIONrmw_cyclonedds_cpp。第二个检查点是消息发布频率是否与仿真器帧率耦合。CARLA的物理迭代频率默认是20HzROS2桥接消息的发布频率和同步效果直接受CARLA的fixed_delta_seconds设定影响。如果你发现桥接话题的频率异常高或者异常低检查CARLA的服务器设置把fixed_delta_seconds设为0.05正好对应20Hz。5.2 PID控制输出正常但车辆不动这个问题的排查逻辑要从上到下游一遍。先发布一个手动控制指令比如ros2 topic pub /carla/ego_vehicle/vehicle_control_cmd carla_msgs/msg/CarlaEgoVehicleControl {throttle: 0.5}如果车辆不动说明问题在低层如果动了说明问题在控制节点的输出端。低层不动通常有两个原因。一是车辆生成了但没有指定角色名称导致桥接节点找不到车辆控制指令发给了空气二是自动驾驶模式没有关掉CARLA自带AI和你的PID在抢控制权。这两个问题我看过太多次尤其是第二个新手特别容易踩。关闭自动驾驶模式的命令是actor.set_autopilot(False)必须在生成车辆后立刻执行。还有一个隐蔽原因是CARLA的车辆控制消息里manual_gear_shift字段如果置True换挡逻辑会变得很奇怪。建议设置为False让CARLA自动管理换挡。否则你可能看到车辆已经挂了一档但控制指令没有生效。5.3 高速工况下PID控制效果差的深层原因如果你在低速下把PID调得很顺一提高到高速巡航空载可能会出现新的问题。比如跟随误差变大、弯道附近速度波动等。核心原因有两个。第一是空气阻力的平方律效应。车速越高阻力越大而且阻力与车速呈非线性关系。PID在线性区间内调好的参数在高速度段可能因为增大的阻尼而出现更大的稳态误差。这时候靠增大P和I是可以改善的但更根本的方案是做增益调度也就是根据车速段采用不同的PID参数或者加入前馈项。我在仿真里用了一个简单的前馈根据目标速度和阻力模型估算一个基础油门开度PID只负责修正误差部分。这样提高了跟踪精度也更接近真实工程的做法。第二是仿真步长带来的延迟问题。CARLA在20Hz固定步长下每个仿真步之间的时间间隔是50ms这个时间内车辆的控制输出不会立即反映到速度变化上。所以高速下误差变化更快PID输出还没有完全作用误差就已经更新了。这时可以尝试把控制频率提高到30Hz或40Hz但要注意CARLA的物理频率上限确保控制频率和物理频率的倍数关系稳定。5.4 常见问题排查表写一个速查表格能帮你节省大量时间这是我在调试中反复使用的问题定位思路。现象优先检查项可能原因解决方向车辆完全无响应手动发布控制指令测试角色名称不匹配/自动驾驶未关/桥接未启动确认车子角色名关闭自动控制车辆只朝一个方向加速检查PID输出符号油门刹车映射逻辑错误输出正负与油门刹车对应关系修正速度来回震荡降低kp观察曲线周期P项过大/控制周期过长减小kp或提高控制频率稳态误差一直存在增加ki积分项缺失/太小逐步增加积分增益起步时一冲一顿查看控制输出是否频繁切换符号死区太小/刹车滞回不足增大死区切换滞回处理高速段误差突然变大检查速度和阻力关系线性PID参数不适应高速原点加入前馈或增益调度消息偶尔断流查看RMW日志与内存设置FastDDS共享内存问题调整共享内存或换RMW这个表格并不是万能的但绝大多数纵向控制联调问题都能在这个框架里定位到方向。还有一个我个人的习惯每调一次参数立刻把参数记录到一张调试日志表里包括时间、场景、参数值、效果截图。这个习惯会让你在几十次调参之后还能精准回溯哪组参数在哪个场景下最有效。6. 从仿真到实车纵控落地的几条务实建议虽然这篇内容主要讲的是CARLA仿真但我还是想聊几句关于“仿真和真车之间的差距”因为很多人拿到一套仿真代码总以为直接换到实车上就能跑。实际上至少有三个方面必须重新考虑。第一个是延迟量级。仿真里控制指令发出到车辆执行延迟基本在几十毫秒内而且不确定性很小。但真车链路上刹车系统、油门执行器的响应时间尤其是气刹或者电子液压制动差异很大。PID的D项对延迟非常敏感在仿真里表现良好的参数在真车上很可能引发剧烈的震荡。第二个是执行器特性。仿真器里的油门和刹车指令可以近似理解为线性的踏板开度但真车发动机的扭矩输出、刹车盘的摩擦系数变化都会带来明显的非线性。所以PID里的输出映射必须从线性映射升级为查表映射根据车速、档位、发动机转速等重新标定。第三个是安全性逻辑。真车上绝不能只靠PID跑纵控至少要加一层“安全限制层”比如限制最大油门变化率、限制最高车速、刹车优先级必须高于油门等。在仿真阶段做一个安全限幅模块养成习惯后移植到真车会省很多事。我见过太多人在仿真里把PID调得赏心悦目到了实车一跑就翻车根本原因不是PID算法本身不行而是低估了真车非线性特性和执行器延迟。所以我的建议是在做CARLA仿真的时候故意给控制链路加一些可以被配置的延迟比如20ms、50ms、100ms观察PID参数的鲁棒性这对后期移植非常有帮助。另外仿真环境里还有一个很容易被忽视的问题CARLA默认的车辆动力学参数和真实车辆的参数差异非常大。相同输出的油门在CARLA里可能是2 m/s²的加速度在真车上可能是5 m/s²。所以仿真里标定的PID参数真实场景只能当作起点不能直接当结果。从我的经验来看做纵向控制最好的路径是CARLA仿真验证算法逻辑、Gazebo或者真实车辆数据回放验证模型差异、封闭场地实车测试执行器手感三步走缺一不可。CARLA最大的价值在于帮你把控制逻辑、消息链路、异常处理这些“软件层”的问题全部暴露出来等到了实车阶段你只需要专注于“物理层”的调校而不需要边调参边排查代码bug。7. 写在最后的一些实操体会CARLA加ROS2加PID这套组合是我换过好几套方案之后才定下来的标配。之前也试过用纯Python脚本跑仿真控制不用ROS2但那样做最大的问题是节点多了以后调度混乱加一个传感器节点、加一个路径节点就得改一堆代码。ROS2把所有模块解耦开之后控制节点只关心速度误差规划节点只关心路径生成调试定位问题的时候边界非常清晰。给刚入门的朋友一个建议PID调参这件事不要过度依赖仿真里的一次完美参数组合而是要建立自己的调试流程和判断标准。什么算是好的纵控我觉得至少有这几个维度稳态误差小、超调量小、响应时间快、控制输出变化平滑。这四个指标往往互相牵制你在一个维度上用力过猛其他维度就会反弹。找到一个均衡点比追求某个单一指标优秀要重要得多。如果你已经把这套流程跑通了下一步可以尝试加一个前馈控制模块或者做一个简单的增益调度再往后可以试试LQR或MPC。但无论你走多远PID这层基础都不会白学。它让你真正理解什么是误差、什么是反馈、什么是系统响应这些是后续一切高级控制算法的地基。最后再分享一个小技巧调PID的时候记得把你每次启动CARLA的地图固定下来。不同地图的路面附着系数差异其实蛮大的尤其是某些城市地图带坡度你会发现同样的PID参数换张地图表现就完全不同。固定测试场景才能让每次调参的结果具有可比性。