1. 线控转向仿真的整体架构与方案选型
线控转向(Steer-by-Wire, SBW)这几年在底盘电控圈子里热度一直往上走,原因很直接:它把方向盘和前轮之间的机械连接彻底拿掉了,转向手感、传动比、路感反馈全部交给电信号和算法来定义。这意味着整车厂可以在一套硬件上标定出完全不同的转向风格,也意味着做控制算法的人有了更大的发挥空间。但问题也随之而来——没有机械硬连接,方向盘转角和前轮转角之间靠什么保证一致?执行电机响应慢了怎么办?传感器信号丢了怎么兜底?这些问题在实车上验证成本极高,所以用Carsim加Simulink做联合仿真,就成了绝大多数团队在前期验证阶段的首选路径。
这套仿真方案能做什么?简单说,它让你在一台电脑上跑通从驾驶员输入、转向控制算法、执行电机模型到整车动力学响应的完整闭环。你可以在里面调PID参数、换控制策略、模拟传感器故障、测试不同车速下的转向跟随性能,而不用碰一次实车。适合谁来参考?做底盘电控标定的工程师、做自动驾驶横向控制的研究生、以及刚接触Carsim和Simulink联合仿真的入门者,都能从这套流程里找到可以直接复用的东西。
我自己的经验是,很多人第一次搭SBW仿真时容易犯一个错误:一上来就把Carsim整车模型和Simulink控制模型连起来跑,结果曲线发散,然后花大量时间在两边来回找问题。实际上正确的做法是先分模块验证,再逐步闭环。下面我把整个搭建过程拆开讲,包括模型怎么建、参数怎么算、接口怎么配、出了问题怎么查。
1.1 为什么选Carsim做整车动力学底座
做线控转向仿真,整车模型的选择很关键。常见的方案有三种:自己用Simulink搭十四自由度模型、用CarSim、用Adams/Car。自己搭模型自由度可控,但轮胎模型和悬架K&C特性很难做得准,尤其是转向系统与悬架的耦合效应,没有实车数据标定基本跑不出可信结果。Adams/Car精度高,但建模周期长,实时性差,做控制算法迭代效率太低。
Carsim的优势在于它内置了经过大量实车验证的轮胎模型(Pacejka系列)和悬架运动学特性,整车响应在常规工况下可信度很高。而且它提供了丰富的输入输出接口,可以直接把方向盘转角、前轮转角、车速、横摆角速度、侧向加速度等信号暴露给Simulink。对于SBW仿真来说,我们最关心的是前轮转角能否准确跟随方向盘指令,以及整车在转向过程中的横摆响应是否合理,Carsim在这两点上都能给出足够可信的结果。
还有一个实际考虑:Carsim的求解速度比Adams快很多,做参数扫描和批量仿真时优势明显。我试过在同一台机器上跑同样的工况,Carsim完成一次10秒仿真大约2到3秒,Adams/Car要十几秒甚至更久。做PID调参这种需要反复迭代的活,速度就是效率。
1.2 Simulink侧的控制架构设计
Simulink这边要搭的是线控转向的核心控制逻辑。整个架构我习惯分成四层:输入处理层、控制算法层、执行器模型层、以及监控与故障处理层。
输入处理层负责接收Carsim输出的方向盘转角信号,同时做信号滤波和合理性检查。方向盘转角传感器在实际系统中会有噪声,仿真里虽然信号干净,但为了贴近真实,我通常还是会加一个低通滤波器,截止频率设在20到30Hz左右,这个后面细说。
控制算法层是核心,包含转向传动比映射和PID控制器。传动比映射负责把方向盘转角转换成目标前轮转角,这个映射可以是固定的,也可以是随车速变化的。PID控制器则负责让实际前轮转角跟踪目标值。
执行器模型层模拟转向执行电机的动态响应。这里可以用一阶惯性环节加饱和限制来近似,也可以用更详细的电机模型。如果只是验证控制策略,一阶惯性加限幅就够了;如果要研究电机电流环的影响,就需要搭更细的模型。
监控与故障处理层在仿真阶段容易被忽略,但我建议一开始就留出接口。比如方向盘转角信号丢失时,系统应该进入安全模式,前轮转角回正或保持当前值。这些逻辑在仿真里验证成本很低,但到了实车上就是功能安全的核心内容。
1.3 联合仿真的接口方案选择
Carsim和Simulink的联合仿真有两种主流方式:一种是用Carsim提供的Simulink S-Function接口,把Carsim模型作为Simulink中的一个模块调用;另一种是通过Carsim的External Mode,两边各自独立运行,通过共享内存或网络通信交换数据。
第一种方式配置简单,所有求解都在Simulink里统一调度,时间步长一致,不会出现数据同步问题。缺点是Carsim模型被编译成S-Function后,修改Carsim内部参数需要重新编译。第二种方式灵活度高,适合Carsim和Simulink分别调试的场景,但配置复杂,容易出现通信延迟和步长不匹配的问题。
对于SBW仿真,我推荐第一种方式。因为转向控制对实时性要求高,数据同步必须严格保证。用S-Function接口,Carsim和Simulink在同一个求解器下运行,步长统一设为0.001秒,能保证控制回路的稳定性。具体配置步骤后面会详细讲。
2. Carsim整车模型搭建与参数配置
Carsim的模型搭建看起来是填表格,但填什么值、为什么填这个值,直接决定仿真结果可不可信。我见过不少人直接用默认的C级车参数跑SBW仿真,结果横摆角速度响应和实车对不上,回头查了半天以为是控制算法的问题,其实是整车参数没配对。
2.1 车型选择与基本参数设定
打开Carsim后,第一步是选车型。Carsim内置了从A级到SUV的多种车型模板,做SBW仿真一般选C级或D级轿车,因为这两类车的转向系统负载和惯量更接近线控转向的典型应用场景。选好模板后,需要重点核对几组参数。
整车质量、轴距、质心高度这三个参数决定了整车的基本转向特性。以C级车为例,典型值大概是整车质量1500kg左右,轴距2.7m,质心高度0.55m。这些值在Carsim模板里都有,但如果你有目标车型的实际数据,一定要替换掉。质心高度对侧倾影响很大,而侧倾又会通过悬架几何影响前轮的实际转角,在SBW仿真里这个耦合不能忽略。
轮胎模型选Pacejka 5.2,这是Carsim里精度最高的轮胎模型。轮胎的侧偏刚度和纵滑刚度需要根据实际轮胎规格调整。如果只是做控制策略验证,用默认值也能跑,但如果你要对比不同轮胎对转向响应的影响,这两个参数就必须改。
悬架K&C特性里,前悬架的侧倾转向系数和后悬架的侧倾转向系数对转向特性影响很大。SBW系统没有机械连接,前轮转角完全由电机决定,但悬架在侧倾时仍会产生附加转角。这个附加转角在Carsim里是自动计算的,你不需要手动加,但需要知道它的存在,否则分析结果时容易困惑。
2.2 转向系统参数的特殊处理
线控转向和传统转向在Carsim里的建模方式不同。传统转向系统有方向盘到前轮的机械传动比,Carsim里直接设一个传动比就行。但SBW没有机械连接,前轮转角是外部输入的,所以需要把Carsim的转向系统设为外部输入模式。
具体操作是在Carsim的转向系统设置里,把转向方式从“Steering Wheel Angle”改成“External Front Wheel Angle”。这样Carsim就不再根据方向盘转角计算前轮转角,而是直接接收Simulink传来的前轮转角信号。这一步很关键,如果忘了改,Simulink算出来的前轮转角根本传不进Carsim,整车不会有任何转向响应。
改完转向方式后,还需要设置前轮转角的输入通道。Carsim的S-Function接口默认有多个输入通道,需要把前轮转角映射到正确的通道上。这个在Carsim的I/O设置里配置,后面讲接口的时候会具体说。
另外,SBW系统里方向盘和前轮之间没有机械连接,但方向盘本身还是有惯量和阻尼的。如果要做方向盘力反馈仿真,需要在Simulink里单独建方向盘模型,Carsim这边只负责整车响应。如果暂时不做力反馈,方向盘模型可以简化成一个角度信号源。
2.3 输出信号的选取与IMU传感器配置
Carsim的输出信号很多,但SBW仿真里必须关注的其实就那几个:前轮实际转角、横摆角速度、侧向加速度、车速、质心侧偏角。前轮实际转角用来和Simulink里的目标转角做对比,评估跟踪性能。横摆角速度和侧向加速度用来评价整车转向响应是否合理。质心侧偏角在高速大转角工况下能反映车辆稳定性。
关于IMU传感器的配置,Carsim里可以在整车模型上添加传感器模块,模拟真实IMU的安装位置和测量噪声。做SBW仿真时,如果控制算法里用到了横摆角速度反馈,就需要从Carsim输出这个信号。Carsim的IMU传感器可以设置在质心位置,也可以设置在其它位置,输出的是该位置的角速度和加速度。我一般设在质心,因为大多数车辆动力学控制算法都基于质心状态。
如果要做传感器故障仿真,比如横摆角速度信号丢失,可以在Simulink侧对Carsim输出的信号做处理,模拟信号中断或漂移。Carsim本身不直接支持传感器故障注入,这部分逻辑在Simulink里实现更灵活。
2.4 仿真工况与求解器设置
Carsim的仿真工况设置包括车速、路面附着系数、转向输入等。做SBW仿真时,我通常先跑几个标准工况:低速大转角(比如车速20km/h,方向盘转角180度)、中速中等转角(车速60km/h,方向盘转角90度)、高速小转角(车速100km/h,方向盘转角30度)。这三个工况能覆盖转向系统的主要工作范围。
路面附着系数先设0.85,模拟干燥沥青路面。等基本功能验证完了,再改到0.3或0.5模拟低附路面,看控制算法在极限工况下的表现。
求解器方面,Carsim默认用定步长求解器,步长可以设0.001秒或0.0005秒。SBW控制回路里有PID,步长太大容易导致积分饱和和振荡。我实测下来0.001秒够用,但如果你的PID参数调得很激进,建议降到0.0005秒。求解器类型选Runge-Kutta 4阶,精度和速度比较平衡。
3. Simulink控制算法集成与PID调参实战
Simulink这边的活是整个SBW仿真里最核心的部分,因为控制算法的好坏直接决定仿真能不能跑通、结果可不可信。我见过太多人卡在PID调参上,曲线要么发散要么响应太慢,最后怀疑是Carsim模型的问题,其实根源在PID参数没配对。
3.1 转向传动比映射的设计
传动比映射是SBW系统的第一个环节,它决定了方向盘转角和前轮目标转角之间的关系。传统转向系统的传动比是固定的,大概在15:1到20:1之间。SBW系统可以做成可变传动比,低速时传动比小,方向盘转一点前轮转得多,停车入库更轻松;高速时传动比大,方向盘转动对应前轮转角小,行驶更稳定。
在Simulink里实现可变传动比,可以用一个一维查表模块,输入是车速,输出是传动比。查表数据根据你的设计目标来定。比如低速20km/h时传动比设10:1,中速60km/h时设15:1,高速100km/h时设20:1。中间值用线性插值。
这里有个细节要注意:传动比映射的输出是前轮目标转角,单位是度还是弧度要和Carsim的输入单位一致。Carsim默认用度,Simulink里如果算出来是弧度,记得加一个弧度转度的模块。这个单位问题看起来小,但一旦搞错,前轮转角会差57.3倍,曲线直接飞掉。
3.2 PID控制器的结构与参数计算
PID控制器是SBW仿真的核心。控制目标是让前轮实际转角跟踪目标转角,控制量是转向执行电机的输出。在Simulink里,PID的输入是目标转角和实际转角的偏差,输出是电机力矩或电机转角指令,具体取决于你的执行器模型。
先讲PID的结构选择。位置式PID和增量式PID在SBW仿真里都有人用。位置式PID输出的是控制量的绝对值,适合执行器直接接收位置指令的场景。增量式PID输出的是控制量的增量,适合执行器接收增量指令的场景。SBW系统里,如果电机控制器接收的是位置指令,用位置式PID;如果接收的是速度或力矩指令,用增量式PID更合适。
我一般用位置式PID,因为仿真里执行器模型通常简化成一阶惯性环节,输入是目标转角,输出是实际转角。位置式PID的输出直接作为执行器的目标转角,物理意义清晰。
PID参数的计算,我习惯先用Ziegler-Nichols方法估一个初值,再手动微调。Ziegler-Nichols的临界比例度法需要先找到系统的临界增益和临界周期。具体做法是把积分和微分增益设为零,只加比例增益,从小到大慢慢加,直到系统输出出现等幅振荡。这时的比例增益就是临界增益Ku,振荡周期就是临界周期Tu。
对于SBW转向系统,我实测下来Ku大概在8到12之间,Tu在0.15到0.25秒之间,具体取决于执行器模型的惯量。有了Ku和Tu,按Ziegler-Nichols公式算:Kp等于0.6倍Ku,Ki等于2倍Kp除以Tu,Kd等于Kp乘以Tu除以8。
算出来的初值大概是Kp=6,Ki=60,Kd=0.15左右。这个初值能让系统稳定,但响应可能偏慢或者超调偏大。接下来就是手动微调。我的经验是先把Kd设为零,调Kp和Ki让系统响应快但不振荡,然后再加Kd抑制超调。
调参的时候盯着三个指标:上升时间、超调量、稳态误差。上升时间要短,但太短了超调会大。超调量控制在5%以内比较理想。稳态误差在积分作用下最终会趋近于零,但如果Ki太小,收敛速度会很慢。
3.3 执行器模型的搭建与参数辨识
执行器模型是连接控制算法和整车模型的桥梁。SBW系统的执行器通常是永磁同步电机加减速机构,仿真里可以用一阶惯性环节加饱和限制来近似。
一阶惯性环节的传递函数是1/(Ts+1),T是时间常数。这个时间常数决定了电机响应目标转角的快慢。实际SBW执行电机的响应时间大概在50到100毫秒之间,所以T取0.05到0.1秒。我一般先取0.08秒,跑完仿真看响应曲线,如果实际转角明显滞后于目标转角,就把T调小。
饱和限制是模拟电机的最大输出能力。前轮转角的最大值受限于转向机构的机械限位,一般乘用车前轮最大转角在35到40度之间。在Simulink里用一个Saturation模块,上限设35度,下限设-35度。
如果要做更精细的电机仿真,可以把电机模型换成带电流环和速度环的双闭环模型。电流环用PI控制器,速度环也用PI控制器,外环是位置环。这种模型能反映电机电流限制对转向响应的影响,但参数辨识工作量大,需要电机的实际参数。如果只是验证转向控制策略,一阶惯性加饱和就够了。
3.4 联合仿真接口的配置与调试
Carsim和Simulink的接口配置是联合仿真最容易出问题的地方。我用的是Carsim的S-Function接口,具体步骤是这样的。
先在Carsim里完成整车模型和工况设置,然后进入I/O设置界面。在输入通道里,把前轮转角加到输入列表里,通道号记下来。在输出通道里,把前轮实际转角、横摆角速度、侧向加速度、车速、质心侧偏角加到输出列表里,通道号也记下来。
然后点Send to Simulink,Carsim会生成一个S-Function模块和一个配套的m文件。在Simulink里新建模型,把S-Function模块拖进去,再在S-Function前面加上输入信号处理,后面加上输出信号处理。
输入信号处理就是把Simulink算出来的前轮转角接到S-Function的对应输入端口。输出信号处理就是把S-Function输出的整车状态信号取出来,送到PID控制器和示波器。
调试的时候,先不要接PID,直接给一个固定的前轮转角信号,看Carsim输出的横摆角速度是否合理。如果横摆角速度一直是零,说明前轮转角没传进Carsim,检查输入通道号是否对应。如果横摆角速度有响应但方向反了,说明前轮转角的符号搞错了,加一个负号。
确认Carsim能正确响应前轮转角后,再把PID接进去闭环。闭环后先给一个小阶跃信号,比如目标前轮转角从0跳到5度,看实际转角能不能跟上。如果实际转角振荡发散,先把PID的积分和微分增益设为零,只留比例增益,从1开始慢慢加,直到系统稳定。
4. 整车联动调试与常见问题排查
模型搭完、接口配好、PID初值也给了,接下来就是整车联动调试。这个阶段最考验耐心,因为问题可能出在Carsim侧、Simulink侧、或者接口上,需要一套系统的排查方法。
4.1 仿真发散的典型原因与解决路径
仿真发散是SBW联合仿真里最常见的问题,表现是曲线在几秒内迅速增大到无穷大或者报错终止。根据我的经验,发散的原因大概有这几类。
第一类是PID参数太激进。比例增益太大或者积分增益太大,都会导致系统振荡发散。排查方法是把积分和微分增益设为零,只留比例增益,从1开始慢慢加。如果比例增益加到很小就发散,那问题不在PID,在别的地方。
第二类是执行器模型的饱和限制没设对。如果饱和上限设得太大,PID输出一个很大的控制量,执行器模型输出一个很大的转角,整车响应剧烈,反馈回来又让PID输出更大,形成正反馈发散。检查饱和限制是否合理,前轮转角上限不要超过40度。
第三类是接口的步长不匹配。Carsim和Simulink的步长如果不一致,数据交换时会出现插值误差,严重时导致发散。确保两边步长都是0.001秒,求解器类型一致。
第四类是单位错误。前轮转角的单位在Carsim里是度,在Simulink里如果算出来是弧度,差57.3倍,系统肯定发散。检查所有涉及角度的信号,确认单位统一。
第五类是符号错误。前轮转角的符号如果反了,PID会变成正反馈。检查Carsim输入通道的符号和Simulink输出的符号是否一致。
排查的时候按这个顺序来:先查单位,再查符号,再查步长,最后查PID参数。单位、符号、步长都是确定性问题,查起来快。PID参数是调优问题,放在最后。
4.2 转向跟踪性能不达标的调优方法
仿真能跑通不发散,但转向跟踪性能不达标,比如上升时间太长、超调太大、稳态误差不为零,这是另一类问题。
上升时间太长,说明系统响应慢。先检查执行器模型的时间常数是不是太大了,T取0.08秒如果还慢,降到0.05秒试试。如果执行器没问题,那就是PID的比例增益太小,适当加大Kp。
超调太大,说明系统阻尼不够。加大Kd能增加阻尼,抑制超调。但Kd太大会放大噪声,仿真里信号干净可能看不出来,实车上会有问题。Kd一般不超过Kp的0.1倍。
稳态误差不为零,说明积分作用不够。加大Ki能消除稳态误差,但Ki太大会导致积分饱和和振荡。如果加大Ki后系统振荡,说明Ki和Kp的比值不对,需要同时调整。
我调PID的时候习惯用MATLAB的PID Tuner工具先自动调一版,然后在Simulink里手动微调。PID Tuner能根据被控对象模型自动算一组参数,虽然不一定最优,但作为初值参考很有价值。被控对象模型可以从Simulink里导出,用Linear Analysis工具做线性化。
4.3 常见报错信息与速查表
联合仿真过程中会遇到各种报错,有些报错信息很直观,有些则比较隐晦。我整理了一个速查表,覆盖了大部分常见问题。
| 报错信息 | 可能原因 | 解决方法 |
|---|---|---|
| S-Function执行错误 | Carsim模型未正确编译 | 重新在Carsim里点Send to Simulink |
| 输入端口维度不匹配 | 输入信号数量与Carsim设置不一致 | 检查Carsim I/O设置的输入通道数 |
| 输出端口维度不匹配 | 输出信号数量与Carsim设置不一致 | 检查Carsim I/O设置的输出通道数 |
| 仿真步长不一致 | Simulink和Carsim步长设置不同 | 两边都设为0.001秒 |
| 代数环错误 | 反馈回路中有直接馈通 | 在反馈路径加单位延迟模块 |
| 积分饱和 | PID积分项累积过大 | 加抗积分饱和逻辑或限制积分项 |
| 信号维度错误 | 标量信号接到了向量端口 | 检查信号线维度,必要时加Mux或Demux |
| 求解器步长太小 | 刚性系统导致求解困难 | 换用ode23t或ode15s求解器 |
这个表里的问题我基本都遇到过,其中代数环错误和积分饱和是最费时间的。代数环错误在闭环控制里很常见,因为PID的输出直接影响到被控对象,被控对象的输出又反馈回PID,形成代数环。解决方法是在反馈路径上加一个单位延迟模块,打破代数环。单位延迟会引入一个步长的延迟,对仿真精度影响很小,但能解决代数环问题。
积分饱和在转向系统里表现为:目标转角突然变大,PID积分项迅速累积,实际转角超调后积分项需要很长时间才能退掉。解决方法是在PID模块里启用抗积分饱和功能,或者自己搭一个积分限幅逻辑。Simulink的PID模块自带抗积分饱和选项,勾上就行。
4.4 仿真结果的可信度验证
仿真跑通了,曲线也好看,但结果可不可信是另一个问题。我一般从三个角度验证。
第一,和理论值对比。比如稳态横摆角速度,可以用二自由度车辆模型的公式算一个理论值,和Carsim输出的稳态值对比。如果差太多,说明整车参数或者轮胎模型有问题。
第二,和实车数据对比。如果有实车测试数据,把同样的工况在仿真里跑一遍,对比横摆角速度和侧向加速度曲线。这是最直接的验证方法,但实车数据往往不好拿。
第三,做参数敏感性分析。改一个参数,比如整车质量增加10%,看仿真结果的变化是否符合预期。如果质量增加后横摆角速度反而变大,那肯定有问题。
我自己的习惯是,每换一套整车参数,先跑一个标准双移线工况,看横摆角速度和侧向加速度的峰值是否在合理范围内。C级车在60km/h双移线工况下,横摆角速度峰值大概在20到30度每秒,侧向加速度峰值在0.4到0.6g。如果仿真结果偏离这个范围太多,就要回头查参数。
5. 进阶扩展与工程化建议
基础仿真跑通之后,可以根据实际项目需求做进一步扩展。这部分内容不是必须的,但如果你要把仿真结果用到实际项目里,这些扩展能显著提升仿真的工程价值。
5.1 从仿真到代码生成的路径
Simulink模型验证完之后,下一步往往是把控制算法生成C代码,刷到实际控制器里。Simulink的Embedded Coder支持从模型直接生成代码,但SBW控制算法生成代码有几个注意点。
第一,PID模块要用支持代码生成的版本。Simulink里有些PID模块是仿真专用的,不支持代码生成。换成PID Controller模块,这个模块支持代码生成。
第二,查表模块的数据要固定。可变传动比映射用的查表模块,表数据在代码生成时会被固化成常量。如果需要在运行时修改传动比,要把表数据做成输入端口,从外部传入。
第三,浮点运算转定点运算。实际控制器可能是定点处理器,需要把Simulink里的浮点运算转成定点。Simulink的Fixed-Point Designer工具能做自动转换,但转换后要重新验证精度。
第四,代码生成配置。在Simulink的Configuration Parameters里,把System target file设成ert.tlc,Language设成C,然后点Generate Code。生成的代码会包含模型里所有模块对应的C函数。
我试过把SBW控制算法生成代码刷到dSPACE的快速原型控制器上,从模型到可运行代码大概半天时间。主要时间花在定点转换和精度验证上,代码生成本身很快。
5.2 传感器故障注入与容错逻辑验证
SBW系统没有机械备份,传感器故障的容错逻辑是功能安全的核心。在仿真里验证容错逻辑,成本比实车低得多。
方向盘转角传感器故障的模拟,可以在Simulink里加一个故障注入模块,在指定时间把转角信号置零或者加一个漂移量。然后观察控制算法是否能检测到故障并进入安全模式。安全模式的策略一般是前轮转角回正或者保持当前值,同时点亮故障灯。
横摆角速度传感器故障的模拟类似,在Carsim输出的横摆角速度信号上加故障注入。如果控制算法里用到了横摆角速度反馈,传感器故障后反馈信号错误,可能导致控制量异常。容错逻辑需要检测信号合理性,比如横摆角速度和侧向加速度的积分是否一致,不一致就判定传感器故障。
故障注入的时机和持续时间要设计好。我一般设三个场景:故障发生在直线行驶时、故障发生在转向过程中、故障发生在转向回正时。这三个场景覆盖了主要的风险工况。
5.3 仿真效率优化与批量跑法
做参数扫描或者蒙特卡洛仿真时,需要批量跑大量工况。Carsim和Simulink联合仿真的单次运行时间大概几秒到几十秒,跑几百次就是几个小时。优化仿真效率有几个实用方法。
第一,用Carsim的Batch Mode。Carsim支持批量运行多个工况,把工况参数做成变量,用脚本循环调用。Simulink这边用sim命令在MATLAB脚本里批量调用模型,比手动点运行快得多。
第二,用快速仿真模式。Carsim有个Quick Run选项,关闭一些不影响转向响应的计算模块,能提速30%左右。但快速模式下的结果精度会略降,适合做参数扫描的初筛,最终验证还是要用完整模式。
第三,并行计算。MATLAB的Parallel Computing Toolbox支持parfor循环,把不同工况分配到多个CPU核心上并行跑。我试过用8核并行,批量仿真时间缩短到原来的1/6左右。
第四,简化模型。如果只是验证PID参数,可以把Carsim的整车模型简化,关掉悬架K&C和轮胎温度模型,只保留基本的车辆动力学。简化后的模型跑得更快,但结果只适合做控制策略验证,不适合做整车性能评估。
5.4 从Carsim到其他仿真平台的迁移思路
有些项目后期可能需要从Carsim迁移到其他仿真平台,比如CarMaker或者自研仿真环境。迁移的核心工作是接口适配和模型参数移植。
接口适配方面,不同仿真平台的输入输出接口定义不同。Carsim的S-Function接口换成CarMaker的接口,需要重新配置输入输出通道映射。控制算法本身不用改,改的是接口层。
模型参数移植方面,整车参数、轮胎参数、悬架参数需要从Carsim的格式转换成目标平台的格式。大部分参数是通用的,但轮胎模型的参数化方式可能不同。Carsim用Pacejka系数,CarMaker可能用MF-Tyre或者其它模型,需要做参数转换。
我自己的经验是,迁移工作量的80%在参数转换和验证上,20%在接口适配。迁移完成后,一定要用同样的工况在两个平台上各跑一遍,对比结果。如果差异在可接受范围内,说明迁移成功。
5.5 实操心得与避坑清单
最后分享几条我在SBW联合仿真里踩过的坑和总结的经验。
第一条,先分模块验证,再闭环联调。Carsim单独跑通、Simulink单独跑通、接口单独跑通,最后再闭环。一上来就闭环,出了问题根本不知道是哪里的问题。
第二条,单位统一是底线。角度用度还是弧度,力矩用牛米还是牛毫米,速度用米每秒还是千米每小时,所有信号的单位在接口文档里写清楚,代码里加注释。单位错误是最低级的错误,但也是最容易犯的。
第三条,PID调参从比例开始。先把积分和微分设为零,只调比例增益,系统稳定后再加积分消除稳态误差,最后加微分抑制超调。跳过比例直接调积分和微分,大概率调不出来。
第四条,仿真步长宁小勿大。0.001秒是底线,如果系统刚性大,降到0.0005秒。步长太大导致的数值误差,有时候看起来像控制问题,实际上是求解器的问题。
第五条,保存每一版能跑通的模型。PID调参过程中会改很多参数,改来改去可能把之前能跑通的版本改坏了。每调出一版能跑通的参数,就另存一个模型文件,文件名带上日期和参数版本。这个习惯在后期对比不同控制策略时特别有用。
第六条,示波器要分组。Simulink里的示波器如果所有信号都堆在一起,曲线根本看不清。我习惯分三组:第一组看转角跟踪(目标转角和实际转角),第二组看整车响应(横摆角速度和侧向加速度),第三组看控制量(PID输出和执行器输出)。分组看曲线,问题定位快很多。
第七条,Carsim的动画要开着。Carsim的3D动画能直观看到车辆的运动轨迹和姿态,有时候曲线看不出问题,动画一看就发现车辆在画龙或者侧滑。动画和曲线结合着看,效率更高。
这套SBW联合仿真的流程,我从第一次搭到现在大概迭代了七八个版本,每次遇到新问题就补一条经验进去。现在跑一个完整的SBW仿真,从打开Carsim到出结果,熟练的话半天能搞定。但第一次搭的时候,光接口配置就折腾了两天。希望这些内容能帮你少走一些弯路。