开车摸过方向盘的人都知道，真实驾驶员的操作不是一组设定好的信号，而是根据路况、车速、车身姿态不断修正的闭环过程。上一轮carsim与simulink联合仿真学习笔记里，我还在用固定的油门和转向输入跑开环工况，车辆虽然能按我给的信号走，但稍微加点速度误差、路面扰动，轨迹就开始飘。这次把目标直接推进到driver model仿真：让驾驶员模型自己去"看路"、"修正"、"操作"，而C-class车模上那5个driver sensors，就是驾驶员"感知"车辆状态的核心反馈通道。
这篇文章我不会讲太多花哨的东西，重点就三件事：C-class车模怎么选、怎么配；driver model仿真中5个driver sensors到底代表什么、怎么接进Simulink；以及从开环切换到闭环之后，我自己踩过的几个坑和调参思路。适合正在做车辆动力学联合仿真的研究生、工程师，或者刚把carsim和simulink连通、想进一步做驾驶员闭环控制的人。
1. 为什么这次要折腾driver sensors
1.1 上一阶段打好的底子
上一篇笔记结束时，我其实只做通了最基本的"数据通路"：CarSim负责解算车辆动力学，Simulink负责给控制信号。用今天的话讲，那还是个"开环玩具"——我把方向盘转角一路接到CarSim的输入通道，车辆就按固定转角转圈，油门给多少它就加速到多少，整个过程没有反馈，车辆到底处于什么状态，Simulink侧其实是"盲"的。
那种模式的局限非常明显。速度一高，车辆对转向输入的响应就会因为轮胎侧偏特性发生变化，同样的方向盘转角在不同车速下转弯半径完全不同。开环仿真里我根本感知不到这种变化，只能一遍遍试参数，效率很低。
1.2 从开环到闭环：这场仿真的目标是什么
所以这次学习的核心目标就一个字：闭。让驾驶员模型能实时看到车速、横摆角速度、横向偏差这些状态量，再根据状态误差去修正转向、油门和制动操作。这样才像"人开车"，而不是"放录像"。
在CarSim里做闭环驾驶员仿真，最关键的一步就是把车辆状态反馈给驾驶员模型。反馈通道里有一类信号特别重要，就是driver sensors。它虽然不是某个传感器硬件，而是CarSim输出的五路驾驶员相关信号，但作用等价于真车上驾驶员通过手脚感知到的车辆反馈——转向盘反馈、油门执行情况、制动执行情况、档位实际位置、离合器状态。
1.3 看了几篇论文之后，我选择了C-Class
为什么选C-class车模？老实说，最初想用更简单的车型，但翻了CarSim自带数据库和相关论文之后发现，C-Class几乎是做driver model仿真的"默认选项"。
原因有三。第一，C-Class的整车参数非常中庸，轴距、轮距、质心高度、簧载质量都在中级轿车的典型区间，不会像跑车那样对转向输入极度敏感，也不会像SUV那样侧倾大得离谱，适合验证一般性的驾驶员控制算法；第二，它的悬架K特性、C特性在CarSim里标定得比较完整，稳态回转、变道、制动等工况都能跑出合理响应；第三，论文里用C-Class做基准车型的案例多，参数和现象都有参照，出了问题容易判断是算法的问题还是车辆模型的问题。
2. C-Class车模的配置清单与应用判断
2.1 C-Class车型在CarSim数据库里的定位
在CarSim的主界面里，C-Class属于基础车型库，通常在"Vehicle"分类下可以找到。它不是某个具体品牌车型，而是一组能代表"中型轿车"这一类车辆的参数集合。数据库里包含车身、动力总成、制动系统、转向系统、轮胎、悬架等各个子系统。
我用它做联合仿真时，第一步不是改参数，而是把整车参数页面整体过一遍。CarSim的车辆参数是通过左侧树形菜单组织起来的，每个子系统是一个页面，页面里的参数又可以分为"刚性参数"和"特性曲线"两类。刚性参数包括质量、质心位置、轴距、轮距这些，特性曲线包括悬架刚度、阻尼、轮胎侧偏特性等。
2.2 必须检查的车辆参数项
虽然C-Class默认参数已经比较合理，但有几个位置我建议动手之前就确认，否则后面仿真报出奇怪的结果，回溯起来非常费劲。
- 整车质量和质心位置：默认设置下C-Class整备质量通常在1.5吨上下，质心高度在0.5米量级。如果后面要修改载荷工况，记得同步调整转动惯量，否则车辆动态响应会失真。
- 轮胎模型：CarSim自带多种轮胎模型，我通常用内置的"Internal Tire Model"而不是第三方魔术公式轮胎。内置模型的参数是跟C-Class匹配好的，联合仿真步长下更稳定。
- 转向系统：做driver model仿真时，方向盘转角输入直接进转向系统模型。C-Class默认配置里转向传动比、转向柱摩擦、助力特性都比较典型，不需要动。
- 制动系统：制动主缸压力到轮缸压力的映射关系，是纵向驾驶员控制必须关心的参数。C-Class默认的制动模型线性度不错，适合做基于PID的制动控制。
- 传动系统：做手动挡模型时，需要关注离合器传递能力曲线、各档位速比和换挡时序。这些参数决定了driver sensors里的Gear和Clutch信号是否合理。
2.3 为什么默认参数是第一选择
很多朋友做联合仿真，上来就想把车辆参数改成自己"理想中"的样子，结果模型跑出来的现象和理论对不上，最后找原因发现是参数改出了一堆自洽性问题。我的建议是：第一遍跑通全流程，绝对不要改任何车辆参数，就用C-Class默认配置。
默认参数最直接的优点是"靠谱"。CarSim官方用这套参数做了大量标定和验证，跑标准工况的仿真结果和实车测试趋势一致。第一步就改参数，等于把仿真可信度的根基动摇了，后面不管算法出什么问题，都很难界定是控制问题还是车辆参数问题。我自己就是在用默认参数跑通第一版driver model之后，才开始逐步调整悬架刚度和整车质量做对比实验的。
3. Driver Model仿真的核心：五个driver sensors的来龙去脉
3.1 先把概念分清：driver model、driver controls、driver sensors
这套仿真里最容易把人绕晕的就是这几个名词。
- driver model：驾驶员模型，是实现"人开车"逻辑的算法模块，既可以是CarSim内置的，也可以自己在Simulink里搭。
- driver controls：驾驶员控制指令，是驾驶员模型输出的操作量，对应CarSim的输入通道，比如方向盘转角、油门开度、制动压力、档位、离合器。
- driver sensors：驾驶员传感器，是CarSim从车辆模型里提取出来、反映驾驶员操作实际执行结果的状态量。
三者的关系可以这样理解：driver model是大脑，driver controls是大脑发出的指令，driver sensors是手脚和身体反馈回来的执行结果。做闭环仿真，就是要让"大脑"能同时看到"指令"和"结果"，不断修正差异。
3.2 五个传感器的具体含义与读取方式
标题里的"5 driver sensors"，对应到C-class车模的典型手动挡配置，指的是下面这五个：
| 传感器信号 | CarSim输出变量（典型） | 含义 | 单位 |
|---|---|---|---|
| 方向盘转角 | Steer_SW | 驾驶员施加的方向盘角度，包含左右方向 | deg |
| 油门踏板开度 | Throttle | 油门踏板的实际开度比例 | 0~1 |
| 制动主缸压力 | Brake_MC | 制动系统主缸压力，反映制动力度 | MPa |
| 档位 | Gear | 当前实际接合的档位 | 无量纲（整数） |
| 离合器踏板位置 | Clutch | 离合器踏板行程比例 | 0~1 |
这五个信号里，方向盘转角、油门、制动是任何驾驶员模型都必须反馈的核心量；档位和离合器则是在手动挡模型里需要额外关心的量，尤其在起步、换挡、减速停车这些瞬态工况，它们是否平稳直接决定仿真是否可信。
在CarSim端，这些信号没做特殊配置之前不会自动出现在Simulink里。需要在CarSim的输出变量配置页面（通常叫Output或I/O Channels）里把它们添加进去，并指定输出到联合仿真接口。添加完成后，这些信号的排列顺序就是Simulink侧接收向量时的索引顺序。
3.3 通道顺序错位：我踩过的一个典型坑
这里就牵出一个我实际踩过的坑。第一次做联合仿真时，我在CarSim输出配置里依次添加了Vx、Vy、Yaw_Rate、Steer_SW、Throttle、Brake_MC、Gear、Clutch，觉得顺序没问题。但到了Simulink里用Selector逐个取信号时，发现Brake_MC读出来的数值怎么都对不上，还在0到0.3之间乱跳，而真实踩下制动时这个值应该稳步上升到几MPa。
排查了半天，最后发现是CarSim输出变量页面里有一个默认隐藏的变量排在中间，导致实际输出向量比我以为的多了一路，所有信号索引整体往后错了一位。我在Simulink里按"我以为的顺序"取值，自然全乱了。
这个教训让我养成了一个习惯：无论CarSim界面里显示的顺序看起来多么直观，在Simulink侧接上CarSim S-Function模块后，先用一个Display或Scope模块把输出向量完整拉出来看一遍，对照CarSim输出配置逐个数，确认每一个索引位置对应哪个变量，然后再做Selector切片。
3.4 验证传感器信号是否"对劲"的土办法
通道顺序确认后，还有一个问题：怎么知道这五个传感器信号本身是对的？纯看数字容易麻木，我推荐一个很土但很有效的办法——在Simulink里做一组开环阶跃。
具体操作是，给CarSim的转向输入一个固定角度的阶跃，油门给某个恒定开度，档位和离合器按手动挡操作序列给指令，然后在Scope里同时观察Steer_SW、Throttle、Brake_MC、Gear、Clutch这五个信号的变化。
正常情况下，Steer_SW应该快速跟随输入指令并稳定在目标值附近，Throttle保持恒定开度，Brake_MC在未踩制动时接近0，Gear按照档位命令跳变，Clutch在换挡期间出现"踩下-释放"的波形。如果哪个信号的变化趋势和理论不符，一定是配置出了问题，趁早查，不要等到闭环仿真发散时才手忙脚乱。
4. Simulink侧建模：接口、换算与最小闭环框架
4.1 CarSim S-Function与信号进出配置
CarSim与Simulink联合仿真的标准连接方式是：在Simulink模型里放置一个CarSim S-Function模块（根据版本不同，可能显示为CarSim或VS Commands），这个模块承载了CarSim整车模型的全部动力学解算。
S-Function模块通常有两组端口：
- 输入端口（Import）：接收来自Simulink的控制指令，对应CarSim的输入通道，比如IMP_STEER_SW、IMP_THROTTLE、IMP_BRAKE_MASTER_CYL、IMP_GEAR、IMP_CLUTCH。
- 输出端口（Export）：输出CarSim解算结果，也就是CarSim输出配置里添加的那些变量。
联合仿真时，CarSim主界面的"Run"方式需要设置为与Simulink联合，并在CarSim里指定要使用的Simulink模型路径。每次修改CarSim配置后，需要在Simulink里重新运行一次CarSim S-Function的初始化，让它加载最新的参数文件，否则很容易出现"明明改了参数，仿真结果却不变"的问题。
4.2 单位换算和时序同步不可忽略
CarSim内部解算使用国际单位制，但输出变量为了迎合工程习惯，有些用km/h，有些用deg，这就导致Simulink侧收到的信号单位不统一。比如Vx如果配置成km/h，做纵向控制时不换算成m/s，PID参数会非常难调。
我的习惯是在Simulink的CarSim S-Function输出端口之后，立刻接一组Gain模块做单位换算，把km/h转m/s，把deg转rad，把MPa转Pa。统一单位之后再进入控制逻辑，后面调参数时脑子不会乱。
时序同步这个问题也要重视。Simulink仿真步长和CarSim内部步长是两个概念。CarSim的动力学解算使用变步长积分，但通过S-Function与Simulink交换数据时，数据是离散的，Simulink的采样步长决定了数据交互的节奏。步长太大，控制量更新太慢，高速工况容易发散；步长太小，仿真时间暴涨，效率太低。我自己做C-Class的driver model仿真，通常用固定步长0.001秒，既保证稳定性，又不会慢到难以接受。
4.3 一个可用的最小横向控制框架
搭建闭环Simulink模型时，我没用太复杂的驾驶员模型，用的是经典的预瞄-跟随框架，便于理解也便于排查问题。
这个框架的思路是：每个控制周期里，驾驶员把视线放到前方某个预瞄距离处，计算出当前位置与预瞄点之间的横向偏差和航向偏差，然后根据偏差计算期望的方向盘转角。
具体到Simulink里，我大致是这样搭的：
- 从CarSim输出里取Vx、Yaw_Rate、Station、Lateral偏差这几个状态量。
- 根据当前车速和预瞄时间计算预瞄距离，读取预瞄点处的路径横向坐标。
- 用比例-微分控制计算期望方向盘转角。
- 把期望转角限幅后写到CarSim的转向输入通道。
这套框架的优势在于，控制器的物理意义非常直观。Kp大了，转向响应快但容易振荡；Kd大了，系统稳定但转向变迟钝。调参时能很清楚自己在动什么。
4.4 纵向速度跟随的简单实现
横向控制管方向，纵向控制管速度。我在做C-Class速度跟随时的做法是：目标车速和当前车速的误差进一个PID控制器，输出一个宏观的加速/减速需求，然后根据这个需求决定踩油门还是踩制动。
这里有两条路可以走。简单做法是：误差为正就输出油门开度，误差为负就输出制动压力，中间设一个死区，避免油门和制动频繁切换。进阶做法是：用一条Map表把速度误差映射成油门开度和制动压力的组合，模拟真实驾驶员对不同速度误差的操作力度差异。
我没有一上来就上Map表，因为Map表里的标定数据需要大量实验来攒，第一版还是先用的带死区的PID。等闭环跑稳了，再逐步加入Map表来优化跟车平顺性。
需要注意的是，纵向控制输出要经过限幅和变化率限制。真实驾驶员踩油门不会一瞬间从0踩到1，Simulink里直接这样输出会让车辆纵向加速度剧烈跳变。加一个Rate Limiter或者一阶惯性滤波，模拟驾驶员的肌肉响应特性，车辆行为会自然很多。
5. 联调阶段实录：从发散到稳定的调参过程
5.1 第一跑就发散了：定位思路
把最小的闭环框架搭好后，我第一次跑联合仿真，结果非常"符合预期"地发散了。车速还没到20km/h，方向盘转角就开始来回猛打，车辆轨迹扭成麻花。
遇到发散，先不要急着调PID。我第一个动作是回看前面提到的开环阶跃结果，确认五个driver sensors和车辆状态反馈都正常。然后才把注意力放到控制环节上。那次发散的根源，最后定位在预瞄距离设置上——车速低的时候预瞄距离设得太远，驾驶员模型看到的"前方路况"和当前状态差距太大，纠偏力度过猛，形成振荡。
调参顺序我后来固定成这样的套路：先调横向，再调纵向；横向里先调预瞄距离，再调PID增益；纵向里先调死区，再调PID增益。一次只动一个参数，改完看仿真曲线，不要同时动三个，否则出了问题根本定位不到是谁引起的。
5.2 转向振荡和驾驶不自然的参数调整
第二种常见问题是仿真不发散，但驾驶行为特别不自然，典型症状是方向盘转角频繁换向，像是驾驶员在"抖舵"。
这种情况我会优先检查传感器信号的噪声和量化问题。CarSim输出信号本身比较干净，但如果Simulink侧做了滤波，滤波器的相位延迟可能让驾驶员模型看到的信号"滞后"于真实状态，导致控制器总是晚半拍纠偏，结果就是来回修正。解决方式是减少滤波阶数，或者适当降低控制增益。
另一个调参经验是：增益的优先级大于滤波。很多时候觉得信号"脏"就去滤波，其实是增益太高导致的高频振荡被误判成信号噪声。先把比例增益降下来，看高频分量是否消失，再考虑滤波。
5.3 仿真步长和效率问题
闭环联调还有一个绕不开的问题：仿真速度。C-Class模型加driver model闭环之后，每个仿真步长的计算量明显增大，跑一个几十秒的工况可能要等好几分钟。
我的经验是，不要全程用同一个步长。调试阶段用0.001秒的固定步长跑，保证稳定；确认算法没问题之后，可以尝试放宽到0.002秒，但一定要对比两者输出曲线的差异，确认没有明显失真再正式使用。
如果实在需要长时程仿真，还有一个技巧：把那些不参与控制回路的信号从CarSim输出配置里暂时移除，减少S-Function的数据交换量。等需要查看结果时再加回来，仿真速度会有可感知的提升。
5.4 几个容易忽略但关键时刻救命的设置
最后分享几个我在联调中被救过命的设置项，篇幅不长但每一条都是拿时间换来的。
- CarSim S-Function模块的初始化方式：每次修改CarSim参数后，在Simulink里要把S-Function重新初始化（Ctrl+D更新模型），否则加载的还是旧参数。
- 求解器类型：Simulink里求解器选择固定步长离散求解器（如ode4或ode5），不要用连续变步长，否则和CarSim的数据交换时间点对不齐。
- 档位和离合器信号在起步工况的特殊性：做手动挡仿真时，起步阶段离合器的滑摩过程对车辆纵向冲击影响极大，如果只控油门不管离合器，车辆会猛蹿一下。简化处理时可以让离合器按固定速率释放，但要想模拟真实起步，离合器信号必须纳入控制逻辑。
- 输出变量的单位统一：做闭环控制前，把CarSim输出的所有车速、角度、压力信号统一换算成一套单位制，我推荐全部换成m/s、rad、Pa，调PID参数时会轻松一个量级。
说回到这次的学习笔记，我最大的体会是：driver model仿真本身不难，难的是从"开环能跑"到"闭环跑稳"这一步的转变。5个driver sensors看起来只是五个信号，但把它们正确地接进Simulink、理解每个信号背后的物理含义、再让控制逻辑对这些信号做出合理响应，这个过程把车辆动力学和控制系统真正串在了一起。下一步我打算把预瞄-跟随框架换成更接近真实驾驶员行为的最优预瞄模型，再引入转向手感反馈，那时候driver sensors里的横向力类信号就得派上更大的用场了。
