赛车算法这题目一听就是大学生方程式圈子里的人才会碰的东西。我当初刚接电车队的算法负责人时也是一脸懵从零开始啃踩了无数坑才把整车控制那套东西跑通。这篇文章就把我这几年的心得整理出来给后面入队的学弟学妹们一条相对顺的路。先交代一下背景我们车队是电动的参加的是中国大学生电动方程式大赛FSEC这套思路也适配传统的燃油车队只是执行器不一样。项目的第一步不急着写代码而是先把“这辆车需要什么”搞清楚把开发环境搭好把基本的数据流捋通。这篇文章是这个系列的第一篇重点讲整体架构设计、开发工具链的选择以及大部分车队起步时最容易忽略的几个问题。1. 整体架构设计一辆赛车需要的算法远比你想象的多很多新人一上来就想写“控制算法”但实际上一辆大学生方程式赛车从你踩下油门到车动起来中间隔着至少五六层逻辑。我给你们拆一下整个算法体系大概分这么几块。1.1 整车控制状态机VCU逻辑这是所有算法的总调度决定了车当前处于什么状态。上电自检、待机、驱动就绪、行车、故障停车、充电模式这些都靠状态机来管理。状态机的核心价值是安全而不是性能。如果状态机设计得混乱后续再牛的控制算法都白搭。我自己吃过亏第一版代码里状态切换条件写得太松结果在测试时出现了“动力没切断”的险情。后来重构时我把所有切换条件都列成一张表每条都加上了超时保护和硬件反馈校验。1.2 驾驶员意图解析就是解释驾驶员踩了多少油门、打了多少方向、刹了多重。电动方程式一般用APPS油门踏板位置传感器和方向盘转角传感器。这一步看着简单但信号滤波、合理性校验、故障冗余都在这层做。我在实际跑车时就遇到过油门踏板信号跳变那一次如果没做合理性校验车就会猝不及防往前窜。1.3 车辆状态估算这是被很多车队忽略的点。ESP车身稳定系统是民用车标配方程式赛车虽然没有那么复杂但滑移率、纵向车速估计这些你要有数。后轮滑移率没见过那你扭矩控制就是盲调。我们早期测试时车轮打滑自己都不知道还是在数据回放里看到后轮速度与GPS车速偏差很大才意识到才开始补这一块。1.4 扭矩分配与驱动控制这是电动方程式区分燃油车的最大特点。电机响应极快扭矩可以精确控制这就给TCS牵引力控制系统和扭矩矢量控制留了很大的发挥空间。这一层也是写代码最多的地方从驱动扭矩请求、滑移率控制、到前后轴扭矩分配逻辑链路最长。1.5 再生制动协调赛车也要跑耐久赛能耗管理同样重要。刹车时要根据电池SOC、电机温度、车速来分配再生制动强度和机械刹车的比例。这一块电路和机械组的接口比较复杂算法上要做的就是给出一个可靠的再生扭矩上限值。1.6 数据采集与标定这一层不直接参与控制但所有控制算法的迭代都靠它。必须把CAN总线上的信号完整录下来再加上时间戳、GPS、IMU数据后期才能做离线仿真和参数标定。很多车队算法写了很多版本但跑得最多的还是第一版为什么因为第二版没有数据支撑没验证过不敢用。整个架构图我就不画了这种文档里画太复杂没好处但你们自己心里要有一张图状态机在最上面下面是信号处理、状态估算然后是控制策略最底层是落地的数据采集和总线通信。2. 开发工具链选型先说结论别走弯路这个话题我放到第二章节是因为我见过太多队伍把时间花在工具纠结上。今天用Simulink明天用C后天说要用ROS结果代码没写几行环境折腾了一个月。作为第一篇直接给你们一套我们现在验证过比较顺的配置。2.1 主控芯片STM32还是英飞凌先说结论如果是新队直接上手STM32系列就够了。更精确一点推荐用STM32F407或者STM32H750性能完全足够全国绝大多数车队也都在用。英飞凌的AURIX系列安全性更高但工具链对新手不太友好资料也少不建议一上来就选。STM32F407的优势是生态成熟教程多开发板便宜坏了不心疼。代码框架可以参考很多开源整车控制器项目。不要觉得它不是车规级芯片就不行全国赛场上用STM32跑完耐久赛的队伍大有人在重点在于你自己的代码可靠性而不在于芯片本身。2.2 编程语言与代码框架裸机还是RTOS控制算法层面我强烈建议用C语言裸机开发配一个简单的时间片调度。原因有几个一是代码好调出问题可以直接看逻辑二是实时性可控三是学生对操作系统的理解不一定深入RTOS调度配置不当反而引入随机延迟。从现在开始构建一个简单的分层代码目录├── app │ ├── main.c │ ├── vehicle_state_machine.c │ ├── torque_path.c │ ├── driver_intent.c │ └── fault_manager.c ├── drivers │ ├── can.c │ ├── adc.c │ └── gpio.c ├── modules │ ├── filters.c │ ├── pid.c │ ├── slip_estimator.c │ └── battery_limiter.c ├── output │ ├── can_tx.c │ └── log_writer.c └── utils ├── math_lib.c └── lookup_table.c把这个结构先立起来再开始写代码。新人最容易犯的错是一口气把一个功能的逻辑全写在一个几百行的大文件里后期改一个参数要翻半天。2.3 开发环境怎么搭后端代码用STM32CubeMX生成初始化代码加上VS Code配EIDE插件写代码用arm-none-eabi-gcc编译下载调试用ST-Link。这套配置免费、轻量、够用不依赖破解版的IDE也能让所有队员都在自己的电脑上跑起来。具体就说一下VS Code配EIDE的坑。第一次配置时如果编译报错找不到stdio.h基本是ARM工具链路径没添加。EIDE插件要求在设置里指定arm-none-eabi-gcc的安装路径别默认一定要定位到你实际安装的bin目录。再一个常见坑是烧录时找不到ST-Link多半是驱动没装或ST-Link固件版本过旧去ST官网下个CubeProgrammer它能一并解决驱动和固件升级。2.4 仿真和离线验证工具代码写完之后不是直接上车得先在电脑上模拟。我的做法是把控制逻辑单独抽出来做成一个纯C模块不依赖任何硬件。然后在自己电脑上写一个模拟环境输入虚拟的油门信号、车速、电池状态看控制输出是否合理。这样调试效率比上车试高一百倍。再往上如果队伍精力够可以用MATLAB/Simulink做部分模块的仿真或者用CarSim一类整车动力学软件跑扭矩矢量控制相关的算法。但注意这些工具只是辅助验证手段不是开发必需品。第一年如果精力有限可以先跳过把实车的逻辑跑通、把数据记录下来更重要。3. 核心模块拆解与实操从最简单的扭矩控制开始写万事开头难我建议第一次上手时选一个功能相对独立、逻辑清晰的模块来切入。扭矩请求解析就是一个很合适的起点它离硬件近、逻辑不复杂、且能立刻看到效果。3.1 扭矩请求链路梳理驾驶员踩下油门APPS输出电压ADC采集后变成数字量经过滤波和合理性检查再映射成扭矩请求百分比最终乘上当前转速下电机允许的最大扭矩得到请求扭矩值。这个链路可以说是所有整车算法的地基。每辆车的APPS和满油门对应的电压值不一样所以上车前必须标定。我们的做法是在纯电模式下用上位机读ADC原始值记录踏板完全松开的电压和完全踩到底的电压然后做成线性映射。float apps_scale(float adc_value, float adc_min, float adc_max) { float normalized (adc_value - adc_min) / (adc_max - adc_min); if (normalized 0.0f) normalized 0.0f; if (normalized 1.0f) normalized 1.0f; return normalized; }这段很简单但有两个细节值得说。一是别直接用原始ADC数值做控制逻辑先归一化这样移植到不同车辆时不用改控制逻辑只改标定参数。二是限幅要放在滤波之前还是之后我的建议是滤波之前先做一个粗限幅防止异常值拉偏滤波器的中间值滤波之后再做一个细限幅保证输出永远在有效范围内。3.2 滑动平均滤波的陷阱新手最常用的滤波是滑动平均但在赛车这种强振动环境下普通滑动平均会引入明显滞后而这个滞后在快速踩油门时就会表现为动力响应慢。一个更好的方案是带方向判断的非对称滤波。上升沿用短时间常数让动力响应更快下降沿用稍长时间常数避免急收油时电机扭矩突变。听起来复杂其实做起来就是一个if判断加两个不同的滤波系数。float asymmetric_filter(float input, float prev_output, float tau_up, float tau_down, float dt) { float alpha; if (input prev_output) { alpha dt / (tau_up dt); } else { alpha dt / (tau_down dt); } return alpha * input (1.0f - alpha) * prev_output; }这算是我实际测试中觉得性价比很高的一个小优化。对油门信号的处理不需要上一堆复杂算法一个非对称低通滤波的效果就比很多花哨的办法要好。3.3 生成扭矩请求在控制策略里最关键的一个模块是扭矩路径。它把驾驶员的请求扭矩经过各种限制器最终输出到电机控制器。限制条件包括电池最大放电功率、电机峰值扭矩、当前转速下的最大扭矩、以及电池和电机的温度降额。这里我贴一个简化的代码流程框架不是完整实现意思是让各位理解架构float torque_arbitration(float request, float max_current_limit, float temp_limit) { float limit motor_torque_speed_limit(current_rpm); limit min(limit, max_current_limit); limit min(limit, temp_limit); return clamp(request, -limit, limit); }写这块代码时一定要想清楚几个限制器的优先级。安全相关的限制永远排在第一位比如电池过温时的降功率其次是硬件性能限制比如电机控制器的最大电流最后才是驾驶体验相关的东西。如果你把驾驶平顺性放在安全限制前面那一旦电池过热导致动力骤降车手在弯心里会受到惊吓甚至引发事故。3.4 为什么不要直接把扭矩请求发出去刚把扭矩路径跑通的时候我发现车在起步时会有明显的冲击。原因很简单驱动电机虽然扭矩响应很快但是车本身从静止到动起来需要克服静摩擦和转动惯量突然给一个大扭矩驱动轮就会瞬间突破附着极限要么打滑要么整个传动系统“哐当”一下。解决办法是加一个扭矩斜率限制器ramp limiter。也就是每毫秒最多允许扭矩增加N牛顿米这个N的选取依据车辆在低速时的加速度耐受度和抓地力来判断。float ramp_limit(float new_output, float old_output, float rise_rate, float fall_rate, float dt) { float delta new_output - old_output; float max_delta; if (delta 0) { max_delta rise_rate * dt; } else { max_delta fall_rate * dt; } if (delta max_delta) delta max_delta; if (delta -max_delta) delta -max_delta; return old_output delta; }这个代码块基本是所有平顺性控制的基石。你也可以把上升速率设计成跟挡位或车速相关但第一版固定值就够了。4. 嵌入式开发中的通信与状态同步赛车的算法写得再好如果CAN通信底层不稳定全白搭。说点在实验室里根本发现不了的问题。4.1 CAN总线丢帧排查CAN总线在实验室测试时往往一切正常插上电机控制器一跑就疯狂丢帧。原因通常是总线负载率过高、终端电阻没有正确匹配、或线束布置存在明显干扰。解决方案分三步走。第一步确认总线两端都接了120欧姆终端电阻至少保证在总线调试口和最后一个节点各有一个第二步降低周期性消息频率比如原来的VCU 10ms发一次可以改成20ms前提是控制周期允许第三步检查CAN_H和CAN_L是否双绞它们的线束必须绞在一起否则高速通信时辐射干扰会直接击穿CAN收发器。4.2 多重状态同步问题很多车队会给整车控制器、电池管理系统、电机控制器各自维护状态但三者之间是通过CAN报文不断广播的这里就有个经典问题如果BMS认为接触器已经断开而VCU还在发送驱动扭矩请求会发生什么正常情况下不应该发生但在故障恢复、上下电切换的边界状态就很有可能出现某一帧CAN报文在状态切换瞬间丢帧导致VCU的故障判断延迟。所以我建议VCU内部不要直接依赖其他控制器的状态计算结果而是要基于自己收到的底层信号重新判断比如BMS是否允许放电不要只看BMS发的“允许”布尔值还要看接触器反馈和母线电压是否有实际建立。这一条的代码实现手段就是增加一个很简单的CAN接收信号超时检测。如果VCU连续150ms没有收到关键报文则认为该节点失去通信直接进入安全状态。这是当时我们车队自查时最容易忽略的盲区。void can_rx_timeout_last_update(int msg_id) { last_rx_time[msg_id] now_us; } bool can_rx_msg_healthy(int msg_id, uint32_t timeout_us) { return (now_us - last_rx_time[msg_id]) timeout_us; }在控制循环的起始处做一次健康检查不健康就拒绝进入驱动模式。这一条是对社会工程学攻击免疫的但对提高比赛安全可靠性非常有用。5. 算法开发中的分层安全机制终于聊到重点了。算法再快没有安全机制兜底在赛场上就是定时炸弹。FSAE赛事对安全回路有硬性要求但那个叫硬件安全回路而我们这里说的是软件层要做的主动安全。5.1 报警状态与故障分级我把故障分成三个等级一级故障可恢复比如电机控制器温度偏高但没到极限。VCU此时需要降功率运行同时仪表盘提示。二级故障需停车比如电机温度超过上限、电池过放、CAN通信丢失。此时VCU应快速、平稳地切断扭矩并在安全条件下制动。三级故障不可恢复比如碰撞信号触发、绝缘故障、BMS断高压。此时VCU不需要自己去控制电机直接把整车控制器切到安全状态等待人工重启。很多新队伍写故障处理时喜欢把所有故障都往一个函数里塞然后直接切断动力。这种办法看似安全但实际问题是在耐久赛中如果因为一点无关紧要的过温就频繁切断动力车辆根本跑不完比赛。合理的故障分级能让车在安全前提下尽量“撑住”直到进站。5.2 软件看门狗与执行周期监控在嵌入式上写算法最怕的是代码中出现死循环或者某个函数执行时间超过预期。一个简单有效的办法是在控制循环的临界处用系统定时器计算本轮循环耗时若超过预设的10ms则标记一次超时。连续三次超时即进入二级故障状态。这个手段在调试阶段特别有用。有一次我把一段浮点运算很重的算法加了进去发现控制循环从10ms飙到了24ms车辆在试验场上已经有了响应迟钝的感觉。如果没有这个监控我可能很久都不会发现因为代码逻辑上看起来没问题纯粹是时间预算超了。5.3 多参数查表与降额设计在赛车上电池和电机的温度直接影响最大可用功率。直接用冷却液温度做线性降额是最简单的办法但我建议你们做一张更精细的查表横轴是电池温度纵轴是电机温度输出是允许的最大功率百分比。这种做法其实就是把两条温度曲线拆开成二维映射。我在调校时发现这样比单独的两个一维表更贴近真实物理约束更好解释“同一电机温度下电池温度不同降额幅度却明显不同”的现象。6. 实际测试与数据复盘流程算法开发完成不是终点真正意义的“从零开始开发”要一直到赛车跑起来、数据回测通过才算一段落。这里分享一套我们常用的测试流程。6.1 台架测试优先所有跟电机和电池相关的算法必须先上电机台架或电池模拟器验证。台架测试能发现大量的接线错误和通信问题而这些问题一旦带上车排查起来成本极高。台架测试时重点关注几个数据电机控制器返回的故障码、母线电压和电流是否跟VCU读到的一致、扭矩请求实发和实际输出的差异有多大。这些数据回来你就能对整车功率链路的可靠性有一个基本把握。6.2 直线跑动标定台架没问题后进行低速直线跑动测试。这个阶段不追求圈速主要标定几个基础参数油门踏板的零位和满量程电压、起步扭矩斜坡速率、低车速时的最大扭矩限制。我们第一次跑车时发现起步瞬间电机会发出刺耳的“嗡嗡”声排查后发现是扭矩斜坡速率设得太快导致电机和齿轮快速冲击。把上升速率从每毫秒2Nm降到0.8Nm后声音明显消失起步也更平稳了。6.3 数据回放与离线调参跑完一圈最重要的不是成绩而是数据文件。我们使用开源的CAN转USB记录仪把整车CAN总线上所有关键帧完整录下来然后用Python脚本在电脑上做数据回放分析。数据回放阶段的核心是绘制出扭矩请求、实际扭矩、车轮转速、车速、油门踏板位置、电池电压这几条曲线观察它们是否存在不合理滞后或异常抖动。如果你发现实际扭矩长时间比请求扭矩小很多说明电机在限功率这可能是温度降额、电池电压跌落或者CAN报文丢失导致的。7. 新队起步最容易踩的坑后面内容我就不一点点按流程写了最后这些识别到的坑是我个人的踩坑总结基本每条背后都有真实事件垫底。这些内容不看也行但看了至少能帮你省两周时间。7.1 别把精力全放在单圈性能上很多新队容易被“圈速”绑架花大量时间调扭矩矢量控制、研究空气动力学套件结果连完赛都不稳定。全国赛场上能稳定完赛的队伍成绩都不会差。如果预算和时间有限先保证稳定再考虑刷圈。7.2 不要过度相信仿真结果仿真能帮你验证控制逻辑但动力学仿真里的路面附着、轮胎特性、电机响应时间和实际相差很多。仿真里很稳的控制参数实车跑起来可能完全另一种表现。凡是牵涉安全的关键参数必须通过实车标定确认不能直接沿用仿真值。7.3 版本管理是重中之重不少车队还用“最终版最终版2”这种文件命名管理代码。我强烈建议第一周就把Git建起来代码库分支策略不需要复杂一条main分支加一条dev分支就够用。所有代码变更通过Pull Request合入至少保证main分支随时处于可编译状态。这个习惯养成后队友之间合作才不容易出故障。7.4 留足算法接口别写死你很难第一版就把所有算法写好。比如扭矩分配第一版可能只是简单均分但后续会加入前后轴差异化。所以从第一版开始就要留好接口用查表或参数配置代替写死在代码里的常数。这种小习惯会在中期标定时节约大量时间。这个系列的第一篇就到这里。下一步我打算详细写扭矩矢量控制的具体实现、滑移率估算和TCS的调参过程。如果你们车队正在卡在某一环节也欢迎把具体问题抛到评论里我看到会挑有代表性的在后续文章里拆开讲。
大学生方程式赛车算法开发全指南：从架构设计到落地实践
赛车算法这题目一听就是大学生方程式圈子里的人才会碰的东西。我当初刚接电车队的算法负责人时也是一脸懵从零开始啃踩了无数坑才把整车控制那套东西跑通。这篇文章就把我这几年的心得整理出来给后面入队的学弟学妹们一条相对顺的路。先交代一下背景我们车队是电动的参加的是中国大学生电动方程式大赛FSEC这套思路也适配传统的燃油车队只是执行器不一样。项目的第一步不急着写代码而是先把“这辆车需要什么”搞清楚把开发环境搭好把基本的数据流捋通。这篇文章是这个系列的第一篇重点讲整体架构设计、开发工具链的选择以及大部分车队起步时最容易忽略的几个问题。1. 整体架构设计一辆赛车需要的算法远比你想象的多很多新人一上来就想写“控制算法”但实际上一辆大学生方程式赛车从你踩下油门到车动起来中间隔着至少五六层逻辑。我给你们拆一下整个算法体系大概分这么几块。1.1 整车控制状态机VCU逻辑这是所有算法的总调度决定了车当前处于什么状态。上电自检、待机、驱动就绪、行车、故障停车、充电模式这些都靠状态机来管理。状态机的核心价值是安全而不是性能。如果状态机设计得混乱后续再牛的控制算法都白搭。我自己吃过亏第一版代码里状态切换条件写得太松结果在测试时出现了“动力没切断”的险情。后来重构时我把所有切换条件都列成一张表每条都加上了超时保护和硬件反馈校验。1.2 驾驶员意图解析就是解释驾驶员踩了多少油门、打了多少方向、刹了多重。电动方程式一般用APPS油门踏板位置传感器和方向盘转角传感器。这一步看着简单但信号滤波、合理性校验、故障冗余都在这层做。我在实际跑车时就遇到过油门踏板信号跳变那一次如果没做合理性校验车就会猝不及防往前窜。1.3 车辆状态估算这是被很多车队忽略的点。ESP车身稳定系统是民用车标配方程式赛车虽然没有那么复杂但滑移率、纵向车速估计这些你要有数。后轮滑移率没见过那你扭矩控制就是盲调。我们早期测试时车轮打滑自己都不知道还是在数据回放里看到后轮速度与GPS车速偏差很大才意识到才开始补这一块。1.4 扭矩分配与驱动控制这是电动方程式区分燃油车的最大特点。电机响应极快扭矩可以精确控制这就给TCS牵引力控制系统和扭矩矢量控制留了很大的发挥空间。这一层也是写代码最多的地方从驱动扭矩请求、滑移率控制、到前后轴扭矩分配逻辑链路最长。1.5 再生制动协调赛车也要跑耐久赛能耗管理同样重要。刹车时要根据电池SOC、电机温度、车速来分配再生制动强度和机械刹车的比例。这一块电路和机械组的接口比较复杂算法上要做的就是给出一个可靠的再生扭矩上限值。1.6 数据采集与标定这一层不直接参与控制但所有控制算法的迭代都靠它。必须把CAN总线上的信号完整录下来再加上时间戳、GPS、IMU数据后期才能做离线仿真和参数标定。很多车队算法写了很多版本但跑得最多的还是第一版为什么因为第二版没有数据支撑没验证过不敢用。整个架构图我就不画了这种文档里画太复杂没好处但你们自己心里要有一张图状态机在最上面下面是信号处理、状态估算然后是控制策略最底层是落地的数据采集和总线通信。2. 开发工具链选型先说结论别走弯路这个话题我放到第二章节是因为我见过太多队伍把时间花在工具纠结上。今天用Simulink明天用C后天说要用ROS结果代码没写几行环境折腾了一个月。作为第一篇直接给你们一套我们现在验证过比较顺的配置。2.1 主控芯片STM32还是英飞凌先说结论如果是新队直接上手STM32系列就够了。更精确一点推荐用STM32F407或者STM32H750性能完全足够全国绝大多数车队也都在用。英飞凌的AURIX系列安全性更高但工具链对新手不太友好资料也少不建议一上来就选。STM32F407的优势是生态成熟教程多开发板便宜坏了不心疼。代码框架可以参考很多开源整车控制器项目。不要觉得它不是车规级芯片就不行全国赛场上用STM32跑完耐久赛的队伍大有人在重点在于你自己的代码可靠性而不在于芯片本身。2.2 编程语言与代码框架裸机还是RTOS控制算法层面我强烈建议用C语言裸机开发配一个简单的时间片调度。原因有几个一是代码好调出问题可以直接看逻辑二是实时性可控三是学生对操作系统的理解不一定深入RTOS调度配置不当反而引入随机延迟。从现在开始构建一个简单的分层代码目录├── app │ ├── main.c │ ├── vehicle_state_machine.c │ ├── torque_path.c │ ├── driver_intent.c │ └── fault_manager.c ├── drivers │ ├── can.c │ ├── adc.c │ └── gpio.c ├── modules │ ├── filters.c │ ├── pid.c │ ├── slip_estimator.c │ └── battery_limiter.c ├── output │ ├── can_tx.c │ └── log_writer.c └── utils ├── math_lib.c └── lookup_table.c把这个结构先立起来再开始写代码。新人最容易犯的错是一口气把一个功能的逻辑全写在一个几百行的大文件里后期改一个参数要翻半天。2.3 开发环境怎么搭后端代码用STM32CubeMX生成初始化代码加上VS Code配EIDE插件写代码用arm-none-eabi-gcc编译下载调试用ST-Link。这套配置免费、轻量、够用不依赖破解版的IDE也能让所有队员都在自己的电脑上跑起来。具体就说一下VS Code配EIDE的坑。第一次配置时如果编译报错找不到stdio.h基本是ARM工具链路径没添加。EIDE插件要求在设置里指定arm-none-eabi-gcc的安装路径别默认一定要定位到你实际安装的bin目录。再一个常见坑是烧录时找不到ST-Link多半是驱动没装或ST-Link固件版本过旧去ST官网下个CubeProgrammer它能一并解决驱动和固件升级。2.4 仿真和离线验证工具代码写完之后不是直接上车得先在电脑上模拟。我的做法是把控制逻辑单独抽出来做成一个纯C模块不依赖任何硬件。然后在自己电脑上写一个模拟环境输入虚拟的油门信号、车速、电池状态看控制输出是否合理。这样调试效率比上车试高一百倍。再往上如果队伍精力够可以用MATLAB/Simulink做部分模块的仿真或者用CarSim一类整车动力学软件跑扭矩矢量控制相关的算法。但注意这些工具只是辅助验证手段不是开发必需品。第一年如果精力有限可以先跳过把实车的逻辑跑通、把数据记录下来更重要。3. 核心模块拆解与实操从最简单的扭矩控制开始写万事开头难我建议第一次上手时选一个功能相对独立、逻辑清晰的模块来切入。扭矩请求解析就是一个很合适的起点它离硬件近、逻辑不复杂、且能立刻看到效果。3.1 扭矩请求链路梳理驾驶员踩下油门APPS输出电压ADC采集后变成数字量经过滤波和合理性检查再映射成扭矩请求百分比最终乘上当前转速下电机允许的最大扭矩得到请求扭矩值。这个链路可以说是所有整车算法的地基。每辆车的APPS和满油门对应的电压值不一样所以上车前必须标定。我们的做法是在纯电模式下用上位机读ADC原始值记录踏板完全松开的电压和完全踩到底的电压然后做成线性映射。float apps_scale(float adc_value, float adc_min, float adc_max) { float normalized (adc_value - adc_min) / (adc_max - adc_min); if (normalized 0.0f) normalized 0.0f; if (normalized 1.0f) normalized 1.0f; return normalized; }这段很简单但有两个细节值得说。一是别直接用原始ADC数值做控制逻辑先归一化这样移植到不同车辆时不用改控制逻辑只改标定参数。二是限幅要放在滤波之前还是之后我的建议是滤波之前先做一个粗限幅防止异常值拉偏滤波器的中间值滤波之后再做一个细限幅保证输出永远在有效范围内。3.2 滑动平均滤波的陷阱新手最常用的滤波是滑动平均但在赛车这种强振动环境下普通滑动平均会引入明显滞后而这个滞后在快速踩油门时就会表现为动力响应慢。一个更好的方案是带方向判断的非对称滤波。上升沿用短时间常数让动力响应更快下降沿用稍长时间常数避免急收油时电机扭矩突变。听起来复杂其实做起来就是一个if判断加两个不同的滤波系数。float asymmetric_filter(float input, float prev_output, float tau_up, float tau_down, float dt) { float alpha; if (input prev_output) { alpha dt / (tau_up dt); } else { alpha dt / (tau_down dt); } return alpha * input (1.0f - alpha) * prev_output; }这算是我实际测试中觉得性价比很高的一个小优化。对油门信号的处理不需要上一堆复杂算法一个非对称低通滤波的效果就比很多花哨的办法要好。3.3 生成扭矩请求在控制策略里最关键的一个模块是扭矩路径。它把驾驶员的请求扭矩经过各种限制器最终输出到电机控制器。限制条件包括电池最大放电功率、电机峰值扭矩、当前转速下的最大扭矩、以及电池和电机的温度降额。这里我贴一个简化的代码流程框架不是完整实现意思是让各位理解架构float torque_arbitration(float request, float max_current_limit, float temp_limit) { float limit motor_torque_speed_limit(current_rpm); limit min(limit, max_current_limit); limit min(limit, temp_limit); return clamp(request, -limit, limit); }写这块代码时一定要想清楚几个限制器的优先级。安全相关的限制永远排在第一位比如电池过温时的降功率其次是硬件性能限制比如电机控制器的最大电流最后才是驾驶体验相关的东西。如果你把驾驶平顺性放在安全限制前面那一旦电池过热导致动力骤降车手在弯心里会受到惊吓甚至引发事故。3.4 为什么不要直接把扭矩请求发出去刚把扭矩路径跑通的时候我发现车在起步时会有明显的冲击。原因很简单驱动电机虽然扭矩响应很快但是车本身从静止到动起来需要克服静摩擦和转动惯量突然给一个大扭矩驱动轮就会瞬间突破附着极限要么打滑要么整个传动系统“哐当”一下。解决办法是加一个扭矩斜率限制器ramp limiter。也就是每毫秒最多允许扭矩增加N牛顿米这个N的选取依据车辆在低速时的加速度耐受度和抓地力来判断。float ramp_limit(float new_output, float old_output, float rise_rate, float fall_rate, float dt) { float delta new_output - old_output; float max_delta; if (delta 0) { max_delta rise_rate * dt; } else { max_delta fall_rate * dt; } if (delta max_delta) delta max_delta; if (delta -max_delta) delta -max_delta; return old_output delta; }这个代码块基本是所有平顺性控制的基石。你也可以把上升速率设计成跟挡位或车速相关但第一版固定值就够了。4. 嵌入式开发中的通信与状态同步赛车的算法写得再好如果CAN通信底层不稳定全白搭。说点在实验室里根本发现不了的问题。4.1 CAN总线丢帧排查CAN总线在实验室测试时往往一切正常插上电机控制器一跑就疯狂丢帧。原因通常是总线负载率过高、终端电阻没有正确匹配、或线束布置存在明显干扰。解决方案分三步走。第一步确认总线两端都接了120欧姆终端电阻至少保证在总线调试口和最后一个节点各有一个第二步降低周期性消息频率比如原来的VCU 10ms发一次可以改成20ms前提是控制周期允许第三步检查CAN_H和CAN_L是否双绞它们的线束必须绞在一起否则高速通信时辐射干扰会直接击穿CAN收发器。4.2 多重状态同步问题很多车队会给整车控制器、电池管理系统、电机控制器各自维护状态但三者之间是通过CAN报文不断广播的这里就有个经典问题如果BMS认为接触器已经断开而VCU还在发送驱动扭矩请求会发生什么正常情况下不应该发生但在故障恢复、上下电切换的边界状态就很有可能出现某一帧CAN报文在状态切换瞬间丢帧导致VCU的故障判断延迟。所以我建议VCU内部不要直接依赖其他控制器的状态计算结果而是要基于自己收到的底层信号重新判断比如BMS是否允许放电不要只看BMS发的“允许”布尔值还要看接触器反馈和母线电压是否有实际建立。这一条的代码实现手段就是增加一个很简单的CAN接收信号超时检测。如果VCU连续150ms没有收到关键报文则认为该节点失去通信直接进入安全状态。这是当时我们车队自查时最容易忽略的盲区。void can_rx_timeout_last_update(int msg_id) { last_rx_time[msg_id] now_us; } bool can_rx_msg_healthy(int msg_id, uint32_t timeout_us) { return (now_us - last_rx_time[msg_id]) timeout_us; }在控制循环的起始处做一次健康检查不健康就拒绝进入驱动模式。这一条是对社会工程学攻击免疫的但对提高比赛安全可靠性非常有用。5. 算法开发中的分层安全机制终于聊到重点了。算法再快没有安全机制兜底在赛场上就是定时炸弹。FSAE赛事对安全回路有硬性要求但那个叫硬件安全回路而我们这里说的是软件层要做的主动安全。5.1 报警状态与故障分级我把故障分成三个等级一级故障可恢复比如电机控制器温度偏高但没到极限。VCU此时需要降功率运行同时仪表盘提示。二级故障需停车比如电机温度超过上限、电池过放、CAN通信丢失。此时VCU应快速、平稳地切断扭矩并在安全条件下制动。三级故障不可恢复比如碰撞信号触发、绝缘故障、BMS断高压。此时VCU不需要自己去控制电机直接把整车控制器切到安全状态等待人工重启。很多新队伍写故障处理时喜欢把所有故障都往一个函数里塞然后直接切断动力。这种办法看似安全但实际问题是在耐久赛中如果因为一点无关紧要的过温就频繁切断动力车辆根本跑不完比赛。合理的故障分级能让车在安全前提下尽量“撑住”直到进站。5.2 软件看门狗与执行周期监控在嵌入式上写算法最怕的是代码中出现死循环或者某个函数执行时间超过预期。一个简单有效的办法是在控制循环的临界处用系统定时器计算本轮循环耗时若超过预设的10ms则标记一次超时。连续三次超时即进入二级故障状态。这个手段在调试阶段特别有用。有一次我把一段浮点运算很重的算法加了进去发现控制循环从10ms飙到了24ms车辆在试验场上已经有了响应迟钝的感觉。如果没有这个监控我可能很久都不会发现因为代码逻辑上看起来没问题纯粹是时间预算超了。5.3 多参数查表与降额设计在赛车上电池和电机的温度直接影响最大可用功率。直接用冷却液温度做线性降额是最简单的办法但我建议你们做一张更精细的查表横轴是电池温度纵轴是电机温度输出是允许的最大功率百分比。这种做法其实就是把两条温度曲线拆开成二维映射。我在调校时发现这样比单独的两个一维表更贴近真实物理约束更好解释“同一电机温度下电池温度不同降额幅度却明显不同”的现象。6. 实际测试与数据复盘流程算法开发完成不是终点真正意义的“从零开始开发”要一直到赛车跑起来、数据回测通过才算一段落。这里分享一套我们常用的测试流程。6.1 台架测试优先所有跟电机和电池相关的算法必须先上电机台架或电池模拟器验证。台架测试能发现大量的接线错误和通信问题而这些问题一旦带上车排查起来成本极高。台架测试时重点关注几个数据电机控制器返回的故障码、母线电压和电流是否跟VCU读到的一致、扭矩请求实发和实际输出的差异有多大。这些数据回来你就能对整车功率链路的可靠性有一个基本把握。6.2 直线跑动标定台架没问题后进行低速直线跑动测试。这个阶段不追求圈速主要标定几个基础参数油门踏板的零位和满量程电压、起步扭矩斜坡速率、低车速时的最大扭矩限制。我们第一次跑车时发现起步瞬间电机会发出刺耳的“嗡嗡”声排查后发现是扭矩斜坡速率设得太快导致电机和齿轮快速冲击。把上升速率从每毫秒2Nm降到0.8Nm后声音明显消失起步也更平稳了。6.3 数据回放与离线调参跑完一圈最重要的不是成绩而是数据文件。我们使用开源的CAN转USB记录仪把整车CAN总线上所有关键帧完整录下来然后用Python脚本在电脑上做数据回放分析。数据回放阶段的核心是绘制出扭矩请求、实际扭矩、车轮转速、车速、油门踏板位置、电池电压这几条曲线观察它们是否存在不合理滞后或异常抖动。如果你发现实际扭矩长时间比请求扭矩小很多说明电机在限功率这可能是温度降额、电池电压跌落或者CAN报文丢失导致的。7. 新队起步最容易踩的坑后面内容我就不一点点按流程写了最后这些识别到的坑是我个人的踩坑总结基本每条背后都有真实事件垫底。这些内容不看也行但看了至少能帮你省两周时间。7.1 别把精力全放在单圈性能上很多新队容易被“圈速”绑架花大量时间调扭矩矢量控制、研究空气动力学套件结果连完赛都不稳定。全国赛场上能稳定完赛的队伍成绩都不会差。如果预算和时间有限先保证稳定再考虑刷圈。7.2 不要过度相信仿真结果仿真能帮你验证控制逻辑但动力学仿真里的路面附着、轮胎特性、电机响应时间和实际相差很多。仿真里很稳的控制参数实车跑起来可能完全另一种表现。凡是牵涉安全的关键参数必须通过实车标定确认不能直接沿用仿真值。7.3 版本管理是重中之重不少车队还用“最终版最终版2”这种文件命名管理代码。我强烈建议第一周就把Git建起来代码库分支策略不需要复杂一条main分支加一条dev分支就够用。所有代码变更通过Pull Request合入至少保证main分支随时处于可编译状态。这个习惯养成后队友之间合作才不容易出故障。7.4 留足算法接口别写死你很难第一版就把所有算法写好。比如扭矩分配第一版可能只是简单均分但后续会加入前后轴差异化。所以从第一版开始就要留好接口用查表或参数配置代替写死在代码里的常数。这种小习惯会在中期标定时节约大量时间。这个系列的第一篇就到这里。下一步我打算详细写扭矩矢量控制的具体实现、滑移率估算和TCS的调参过程。如果你们车队正在卡在某一环节也欢迎把具体问题抛到评论里我看到会挑有代表性的在后续文章里拆开讲。
