赛车算法不是调参玄学而是从整车视角做系统拆解——这是我从零开始搭建一套电动方程式赛车整车算法的真实记录。参加大学生电动方程式大赛FSEC的团队越来越多但大部分新队伍面对算法两个字时第一反应是懵的到底要写什么从哪开始写用什么语言写到什么程度算完市面上能搜到的资料要么是某个局部模块的论文要么是商业VCU整车控制器的使用说明书真正讲一套完整算法如何从零长出来的内容几乎是空白。这篇是这个系列的第一篇先把骨架搭起来——聊清楚一套大学生电动方程式赛车的算法到底包含什么、各个模块之间怎么协作、以及第一版代码应该怎么组织和落地。适合车队里负责整车控制器、BMS通信、电机控制策略以及刚接手算法但还没理出头绪的同学。1. 先说清楚赛车算法到底在算些什么很多同学以为赛车算法就是写个PID让电机转这误会挺大。FSEC赛车上跑的那套上位机算法本质上是一个实时决策与控制系统它读取驾驶员的操作意图油门踏板、制动踏板、挡位、方向盘转角读取车辆当前状态车速、轮速、电池电压电流、电机温度、BMS告警然后根据这些信息实时计算并输出控制指令电机扭矩请求、制动能量回收强度、仪表显示、故障降功率策略同时还要把异常工况安全地处理掉。从功能域来切分一套完整的整车算法至少包含五个核心域整车状态估算域车速估算、加速度估算、质心侧偏角估算、路面附着利用、SOC荷电状态与SOH健康状态的归一化处理驾驶员意图解析域踏板开度与变化率的滤波、挡位状态机、扭矩请求生成能量管理与扭矩分配域驱动扭矩限制、能量回收策略、前后轴若有四驱或左右轮若带扭矩矢量分配故障诊断与安全保护域BMS告警等级映射、电机控制器故障码处理、绝缘监测、制动超时判断、高压互锁状态实时监控数据记录与调试域CAN总线报文解析与本地记录、标定参数在线修改、上位机实时监控接口这套结构不是我拍脑袋定的而是从赛规安全逻辑和整车电气架构反推出来的。举几个例子赛规要求当制动踏板被踩下时必须切断驱动扭矩并禁止能量回收——这就要求算法必须同时采集制动踏板和油门踏板信号并在扭矩请求生成之前做仲裁。这不是简单的if-else需要考虑信号抖动、传感器失效等边界情况。赛规要求BMS发出严重故障时整车必须在规定时间内进入安全状态——这要求故障处理路径不能依赖复杂的状态机遍历而是要走独立的高优先级快速路径。再看能量管理FSEC 赛车的电池总能量是固定上限的耐力赛要跑22公里怎么把有限电量发挥到极致这就不只是电机控制问题了而是整车的能量调度策略问题。扭矩限制、效率区间保持、制动能量回收深度、驾驶员驾驶风格自适应这些都是算法要做的事。所以说赛车算法的本质是一组围绕整车安全与性能目标的实时决策逻辑它的核心不是一个高深的公式而是一个严谨的系统的工程。把这个认知建立起来后面才不会越写越乱。2. 算法软件开发环境与工具链选型聊完整体架构先落地一层基础设施用什么环境写、用什么工具查问题、代码怎么管理。这一层虽然不直接产出功能但决定了后续效率的上限。2.1 开发语言与运行平台绝大多数大学生车队走两条路线STM32 裸机或 FreeRTOS 跑的 C 语言路线以及装有 Linux 系统的嵌入式控制器比如 NVIDIA Jetson、Up Board 或部分商业 VCU上的 C/Python 混合路线。两条路线各有拥趸。我的建议是如果团队从零起步、没有很强的嵌入式基础先用 C 语言 STM32 系控制器把整车算法骨架跑通这是最稳的路径。为什么三点理由C 语言是嵌入式控制器的母语CAN 外设驱动、ADC 采集、定时器中断这些底层资源几乎都是为 C 准备的资料最多、踩坑成本最低。整车控制算法的实时性要求非常高状态估算和故障保护的控制周期通常是 1ms 到 10msC 语言配合裸机中断或 RTOS 任务调度可以轻松满足。大学车队的人员流动大C 语言几乎人人会一点交接成本低。Python 适合做离线数据分析、标定工具、Simulink 模型验证但不适合直接跑在实时控制器里。如果你所在的车队已经具备一定的电子电气基础甚至有经验丰富的学长带也可以考虑基于 Linux 的控制器方案。它的优势是调试效率高——可以直接 SSH 上去看日志Python 写标定脚本很方便后续如果要上视觉感知甚至自动驾驶方向的算法整个技术栈可以平滑扩展。缺点是实时性相对难保证驱动层出问题排查难度大而且控制器成本高。2.2 代码管理从第一天就引入 Git这是我最想强调的一点。大学车队最大的痛不是代码写不出来而是代码在队员电脑里传来传去最后谁都不知道哪份是最新版本。从项目的第一天就把所有代码放进 Git 仓库至少能解决三个问题版本可追溯哪天改了什么、为什么改全部有记录出问题了一键回滚。并行开发互不干扰整车状态估算和扭矩分配策略完全可以让两个同学在两条分支上开发最后合并。代码备份托管到 GitHub 或 Gitee 的私有仓库队员电脑丢了也不怕。具体落地时建议建三个仓VCU_Algorithm整车算法主仓、VCU_Tools上位机工具、标定脚本、数据解析脚本、VCU_SimulationMATLAB/Simulink 或 Python 仿真模型。2.3 调试与监控工具链代码烧进控制器后怎么知道它跑得好不好这是第二个容易踩的坑。很多车队开发过程中不做数据监控整车一上电就两眼一抹黑出了问题只能靠猜。我的调试工具链是三层结构CAN 分析工具如 PCAN-View、USB-CAN 适配器 上位机软件直接看总线上每个报文的内容验证整车通信是否正常。车载日志记录在算法代码里做环形缓冲区把关键变量车速、扭矩请求、故障标志、BMS 数据周期性写入 SD 卡或 Flash。这个用于赛车跑起来之后的离线分析。上位机标定工具通过 CAN 或串口实时读写算法里的标定参数比如 PID 的 Kp、扭矩限制斜率、滤波系数。这样调参不用反复烧录固件效率提升非常明显。这套工具链第一版不需要做得很漂亮能用就行。很多车队喜欢先去写一个精美的大屏上位机界面结果核心算法还没影。我的建议是反过来先裸奔一个能显示关键变量和修改参数的简单工具等算法稳定了再回头把工具做精致。3. 整车算法软件架构设计分层、模块化与安全隔离上一节聊的是环境这一节进入正题算法代码里面到底怎么组织。很多车队的第一版算法是一个大 while 循环里写 1000 行 if-else把采集、处理、控制、故障判断全部揉在一起。这种写法在验证功能时跑得通一旦开始调试就容易出问题——改了这里那里开始不正常想单独测一下扭矩控制结果整个程序都要烧进去出了一个故障日志里什么都查不到。我在搭建这套算法时采用的是分层架构 模块化组件 安全路径隔离的设计思路这个思路从第一行代码开始贯穿始终。3.1 分层的思路整车算法从底层到顶层分成五层层级名称职责典型内容L0板级支持层单片机外设的初始化和底层驱动CAN 驱动、ADC 采集、GPIO、定时器、看门狗、SD 卡读写L1数据接入层对底层原始数据的封装和预处理CAN 报文解析、踏板信号滤波、速度信号处理、BMS 报文解包L2状态计算层车辆核心状态量的估算与计算车速估算、SOC 归一化、故障等级判定、车辆模式判定L3控制决策层根据状态量生成控制指令扭矩分配、能量回收策略、温度降功率策略、驾驶员意图解析L4执行输出层将控制指令输出到底层执行器扭矩请求发送、仪表显示、故障灯控制、蜂鸣器驱动分层的核心价值是依赖方向清晰。L0 不会去调用 L3 的函数L3 只能通过接口获取 L2 计算好的状态值。这样每一层都可以独立测试、独立调试、独立替换也可以让不同基础的同学并行开发。3.2 模块怎么切分在每一层内部我按功能独立、接口稳定的原则切成若干个模块模块之间通过头文件声明的接口函数通信不直接访问其他模块的内部变量。具体模块划分如下vcu_can.c/hCAN 报文收发、报文解包、报文超时监测vcu_signal.c/h模拟量和数字量信号的采集、滤波、故障诊断信号合理性判断vcu_state.c/h整车状态机上电自检、就绪、驱动、充电、故障等状态切换vcu_estimator.c/h车速估算、其他状态量的计算vcu_torque.c/h驾驶员扭矩请求生成扭矩仲裁和限制vcu_regen.c/h能量回收策略vcu_fault.c/h故障标志管理、故障处理、安全降级策略vcu_data_log.c/h数据记录、标定参数交互每个模块的对外接口控制在 5-10 个函数以内函数命名统一带模块前缀。比如扭矩模块对外就三个接口void vcu_torque_init(void); // 模块初始化 void vcu_torque_set_inputs(float pedal_pos, float brake_pos, float vehicle_speed); // 输入更新 float vcu_torque_get_request(void); // 获取最终扭矩请求为什么要严格控制接口因为接口就是契约。赛车队半年换一拨人如果模块之间乱耦合新接手的人根本不敢动代码。接口稳定了大家各自维护自己的模块出问题也好定位。3.3 安全路径隔离这是整个架构里最不能妥协的部分常规的功能逻辑走正常路径但涉及安全的功能高压互锁断开、BMS 严重故障、制动超时、绝缘故障必须走独立的安全路径。所谓独立指的是它的判定条件、处理流程和正常路径完全分离。具体做法是在 L0 层用独立中断或最高优先级任务处理急停信号和高压互锁信号不经过主循环。在 L1 层的 CAN 接收中断里对 BMS 的严重故障报文做快速判定一旦发现立即置位安全标志。在 L3 层的扭矩仲裁函数开头先查安全标志如果安全标志有效直接跳转到安全扭矩输出通常为 0不再执行正常扭矩计算。这样做的好处是即使正常路径的代码写出了bug只要安全路径没有被破坏赛车仍然可以被安全地限制在安全状态。其实这套思路也是从航天和功能安全标准里借鉴来的。大学生车队不必完全按 ISO 26262 流程走但**安全功能独立于功能逻辑**这个原则值得从第一版就烙进代码里。4. 关键功能模块的算法设计方案架构定好之后就是填充具体算法实现。这一节挑几个最核心、最体现赛车算法特色的模块详细展开。4.1 整车状态机设计整车状态机是整个算法的大脑主框架所有功能模块都围绕当前状态来决策。我的设计包含以下状态INIT上电初始化完成外设初始化、参数加载、自检。STANDBY待机自检通过等待启动信号。此状态下驱动扭矩强制为 0。READY_TO_DRIVE就绪驾驶员按下就绪按钮且满足所有安全条件后进入。电机控制器使能等待油门输入。DRIVING驱动检测到有效油门踏板输入后进入。正常扭矩请求生成。REGEN能量回收制动踏板踩下且满足回收条件时叠加回收扭矩。FAULT故障检测到任何安全等级为 fatal 的故障时立即进入扭矩输出强制为 0点亮故障灯。CHARGING充电状态高压上电且充电枪连接时进入禁止驱动。状态转移的触发条件要写清楚例如从 READY_TO_DRIVE 到 DRIVING 的条件是油门踏板开度 5% 且持续 50ms。为什么要设这个延时防止驾驶员踩油门瞬间的抖动脉冲误触发这在实车上非常常见。状态机实现上我采用查表法而不是一堆 if-elsetypedef struct { VCU_STATE current_state; VCU_STATE_EVENT event; VCU_STATE next_state; } state_transition_t; static const state_transition_t state_table[] { {VCU_STATE_INIT, VCU_EVENT_INIT_DONE, VCU_STATE_STANDBY}, {VCU_STATE_STANDBY, VCU_EVENT_START_PRESSED, VCU_STATE_READY_TO_DRIVE}, {VCU_STATE_READY_TO_DRIVE, VCU_EVENT_THROTTLE_PRESSED, VCU_STATE_DRIVING}, // ... 其他转移 };查表法的好处是状态转移关系一目了然新增状态或事件时只需要往表里加一行不需要改动原有逻辑而且代码执行时间是确定性的。4.2 车速估算比想象中更需要认真对待车速看起来是直接从轮速传感器读一下就行但实际并非如此。FSEC 赛车一般用两个后轮轮速传感器和一个车速传感器或 GPS各传感器都有自己的噪声和失效模式。差速时内外侧轮速不同、轮胎打滑时轮速不等于车速直接拿轮速当车速扭矩控制和能量回收策略都会受影响。我的车速估算方案是基于轮速的加权融合 合理性校验核心逻辑如下float vcu_estimate_vehicle_speed(void) { float wheel_speed_rear_left get_wheel_speed(REAR_LEFT); float wheel_speed_rear_right get_wheel_speed(REAR_RIGHT); float speed_est 0.0f; // 1. 轮速信号合理性检验 bool left_valid is_signal_valid(wheel_speed_rear_left); bool right_valid is_signal_valid(wheel_speed_rear_right); if (left_valid right_valid) { // 2. 正常情况下取两个后轮轮速的较小值驱动轮打滑时不至于高估车速 speed_est MIN(wheel_speed_rear_left, wheel_speed_rear_right); } else if (left_valid) { speed_est wheel_speed_rear_left; } else if (right_valid) { speed_est wheel_speed_rear_right; } else { // 3. 两路都失效进入安全降级模式 vcu_fault_set(VCU_FAULT_SPEED_SENSOR_LOSS); speed_est 0.0f; } // 4. 一阶低通滤波滤除轮速毛刺 static float speed_filtered 0.0f; const float filter_coeff 0.2f; // 通过标定调整 speed_filtered speed_filtered filter_coeff * (speed_est - speed_filtered); return speed_filtered; }这段代码里最核心的是取较小值策略在驱动工况如果内侧轮打滑轮速会大于车速取较小值可以避免把车速估得过大在制动工况如果车轮抱死轮速会小于车速这时较小值会低估车速。为处理这个问题需要在制动时引入参考车速逻辑用加速度积分做辅助估算这部分后续在实战篇展开。4.3 扭矩请求生成从踩多深走多快到踩多深受多少力驾驶员踩油门踏板本质是在表达我想要多大的加速意图算法要把它翻译成电机扭矩请求值。最基础的做法是查表踏板开度对应请求扭矩百分比再乘以当前允许的最大扭矩。但实际项目里我会在这个基础映射之上叠加三组处理变化率限制斜率限制防止驾驶员猛踩油门时扭矩瞬间拉满导致电机电流冲击过大或车辆失稳。限制值可以分正常模式和雨天/低附着模式两套标定。温度降功率曲线电机控制器和电机有各自的工作温度范围超过设定值后要按比例限制最大可用扭矩这叫降功率derating。这条策略在耐力赛中非常重要很多车队在比赛最后阶段因为电机过热被迫降速就是没有做好提前降功率。低电量保护电池 SOC 低到一定阈值时限制急加速时的峰值扭矩避免电池电压瞬间跌落触发欠压保护。扭矩请求的软件结构如下typedef struct { float pedal_position; // 0~1 float brake_position; // 0~1用于安全互锁 float vehicle_speed; // m/s float motor_temp; // ℃ float mosfet_temp; // ℃ float battery_soc; // 0~1 float battery_voltage; // V float battery_current; // A } VCU_TorqueInputs; typedef struct { float torque_request_raw; // 原始请求扭矩 Nm float torque_request_limited;// 限制后的扭矩 Nm uint8_t limit_source; // 限制了什么温度 / 电量 / 斜率 / 安全 } VCU_TorqueOutputs;计算流程是原始映射 → 斜率限制 → 最高可用扭矩仲裁 → 安全标志检查 → 最终输出。4.4 能量回收策略把每一焦耳都捡回来FSEC 耐力赛的胜负手往往不在直道极速而在能量管理。能量回收策略设计得好一圈下来能比对手多回收 10%-15% 的能量这在 22 公里耐力赛里的价值是决定性的。我的回收策略遵循三个原则回收优先级低于安全只要制动踏板踩下且车速高于阈值就进入回收。但如果检测到电池 SOC 超过 95%、电池温度过高或 BMS 禁止充电立即退出回收并切换为纯机械制动。回收扭矩随车速衰减低速时电机反电动势低回收效率差回收扭矩应该逐渐减小到 0避免造成顿挫感。与机械制动协调能量回收扭矩本身是一个制动力会叠加在机械制动之上。如果回收扭矩突然加入驾驶员会感觉车顿了一下。因此回收扭矩的切入要使用斜坡函数平滑建立。一个简单但有效的回收扭矩查表函数float vcu_regen_calc_torque(float brake_pos, float vehicle_speed, float soc) { // 回收允许条件 if (soc 0.95f || vehicle_speed 1.0f) { return 0.0f; } // 基础回收扭矩随制动踏板开度线性增加 float base_regen brake_pos * MAX_REGEN_TORQUE; // 低速衰减系数 float speed_factor vehicle_speed / REGEN_FULL_SPEED; if (speed_factor 1.0f) speed_factor 1.0f; // 高SOC降额 float soc_factor 1.0f; if (soc 0.85f) { soc_factor (1.0f - soc) / 0.15f; } return base_regen * speed_factor * soc_factor; }实际标定时要注意 MAX_REGEN_TORQUE 不能设得过大。回收扭矩过大会导致后轮在低附着路面上突然抱死车尾瞬间甩起来——在赛场上这是高风险事故。我的经验是先把 MAX_REGEN_TORQUE 设为电机峰值扭矩的 20%再逐步往上调每次增加 5%并配合实车制动测试确认稳定性。5. 从代码写完到车上能跑测试与标定的关键路径代码写完只是开始真正决定算法能否上车的是接下来的测试与标定环节。很多车队在这一步翻了大跟头。5.1 测试层级规划我习惯把测试分成四级单元测试在 PC 上对每个模块的核心逻辑做输入输出验证。比如扭矩查表函数、状态机转移逻辑、SOC 降额计算都是纯数学逻辑完全可以脱离硬件测试。C 语言可以用 Unity 框架或简单写个 main 函数来跑。硬件在环测试HIL把算法烧进真实的 VCU 控制器通过 CAN 报文模拟器向 VCU 发送模拟的传感器数据和 BMS 数据验证算法在真实硬件环境下的行为。这个阶段不需要整车只需要控制器、电源、CAN 工具和一台上位机。HIL 测试能抓住大量时序问题比如中断优先级冲突、任务超时。台架测试把电机和电机控制器接上通过手动或简单机械结构模拟负载验证扭矩请求到电机输出的通路是否正常、电流是否在预期范围内。整车测试从低速直线起步开始逐步扩展到制动回收、蛇形绕桩、动态工况。大部分车队的问题是跳级代码写完直接上整车一个故障接着一个故障既分不清是算法问题还是接线问题也分不清是控制问题还是机械问题。分级测试虽然前期投入大但越到后期越省时间。5.2 一个最容易忽视的坑CAN 报文超时处理CAN 通信有一个典型故障某个报文因为线束松动、节点掉线等原因突然不发了。如果算法里没有超时监测控制器会一直沿用最后一帧的数据这在高压系统里极其危险。我的解决办法在 L1 数据接入层统一做报文超时监测每个关键报文尤其是 BMS 状态报文分配一个新鲜度计数器。接收中断里每收到一帧就清零主循环里周期性对计数器加一。如果某个报文超过设定时间比如 100ms没有更新就置位对应故障标志并触发降级逻辑。void vcu_can_monitor_timeout(void) { for (int i 0; i VCU_CAN_MSG_COUNT; i) { if (can_frame_age[i] CAN_TIMEOUT_COUNTER) { can_frame_age[i]; if (can_frame_age[i] CAN_TIMEOUT_COUNTER) { vcu_fault_set(can_frame_fault_map[i]); can_frame_ok[i] false; } } } }这个机制必须在 HIL 阶段就测到位人为拔掉某路 CAN 节点观察算法是否能在规定时间内进入安全状态。5.3 标定参数管理的艺术算法里会有一堆可调参数滤波系数、扭矩斜率、温度降额阈值、状态机延时等等。这些参数如果全部硬编码在源代码里每次调参都要重新编译烧录效率极低而且很容易调乱了忘了原来在哪。我的做法是定义一个标定参数结构体集中管理所有可调参数。参数保存一段独立的 Flash 区域程序启动时加载同时通过 CAN 或串口提供在线读写接口上位机工具可以直接修改参数并写回 Flash。typedef struct { float pedal_filter_coeff; // 油门踏板滤波系数 float brake_filter_coeff; // 制动踏板滤波系数 float torque_slope_up; // 扭矩上升斜率 float torque_slope_down; // 扭矩下降斜率 float max_regen_torque; // 最大回收扭矩 float motor_temp_derate_start; // 电机降功率起始温度 float motor_temp_derate_end; // 电机完全降功率温度 } VCU_CalibParams; VCU_CalibParams vcu_calib_params;参数集要加上版本号和 CRC 校验防止数据损坏时算法用了垃圾参数。这个系列的第一篇先讲到这里。架构和基础模块搭好之后后面几篇会分别展开状态估算的详细推导、扭矩仲裁的安全逻辑、能量回收的精细策略、以及 HIL 台架的搭建和标定流程。以我的经验第一版代码可能不够完美但只要架构清晰、测试路径明确后面每个迭代都会越走越快。 
长河君 · 2026/9/4 12:28:19 · 阅读 1.2k 电动方程式赛车整车算法实战：从架构拆解到关键模块设计
赛车算法不是调参玄学而是从整车视角做系统拆解——这是我从零开始搭建一套电动方程式赛车整车算法的真实记录。参加大学生电动方程式大赛FSEC的团队越来越多但大部分新队伍面对算法两个字时第一反应是懵的到底要写什么从哪开始写用什么语言写到什么程度算完市面上能搜到的资料要么是某个局部模块的论文要么是商业VCU整车控制器的使用说明书真正讲一套完整算法如何从零长出来的内容几乎是空白。这篇是这个系列的第一篇先把骨架搭起来——聊清楚一套大学生电动方程式赛车的算法到底包含什么、各个模块之间怎么协作、以及第一版代码应该怎么组织和落地。适合车队里负责整车控制器、BMS通信、电机控制策略以及刚接手算法但还没理出头绪的同学。1. 先说清楚赛车算法到底在算些什么很多同学以为赛车算法就是写个PID让电机转这误会挺大。FSEC赛车上跑的那套上位机算法本质上是一个实时决策与控制系统它读取驾驶员的操作意图油门踏板、制动踏板、挡位、方向盘转角读取车辆当前状态车速、轮速、电池电压电流、电机温度、BMS告警然后根据这些信息实时计算并输出控制指令电机扭矩请求、制动能量回收强度、仪表显示、故障降功率策略同时还要把异常工况安全地处理掉。从功能域来切分一套完整的整车算法至少包含五个核心域整车状态估算域车速估算、加速度估算、质心侧偏角估算、路面附着利用、SOC荷电状态与SOH健康状态的归一化处理驾驶员意图解析域踏板开度与变化率的滤波、挡位状态机、扭矩请求生成能量管理与扭矩分配域驱动扭矩限制、能量回收策略、前后轴若有四驱或左右轮若带扭矩矢量分配故障诊断与安全保护域BMS告警等级映射、电机控制器故障码处理、绝缘监测、制动超时判断、高压互锁状态实时监控数据记录与调试域CAN总线报文解析与本地记录、标定参数在线修改、上位机实时监控接口这套结构不是我拍脑袋定的而是从赛规安全逻辑和整车电气架构反推出来的。举几个例子赛规要求当制动踏板被踩下时必须切断驱动扭矩并禁止能量回收——这就要求算法必须同时采集制动踏板和油门踏板信号并在扭矩请求生成之前做仲裁。这不是简单的if-else需要考虑信号抖动、传感器失效等边界情况。赛规要求BMS发出严重故障时整车必须在规定时间内进入安全状态——这要求故障处理路径不能依赖复杂的状态机遍历而是要走独立的高优先级快速路径。再看能量管理FSEC 赛车的电池总能量是固定上限的耐力赛要跑22公里怎么把有限电量发挥到极致这就不只是电机控制问题了而是整车的能量调度策略问题。扭矩限制、效率区间保持、制动能量回收深度、驾驶员驾驶风格自适应这些都是算法要做的事。所以说赛车算法的本质是一组围绕整车安全与性能目标的实时决策逻辑它的核心不是一个高深的公式而是一个严谨的系统的工程。把这个认知建立起来后面才不会越写越乱。2. 算法软件开发环境与工具链选型聊完整体架构先落地一层基础设施用什么环境写、用什么工具查问题、代码怎么管理。这一层虽然不直接产出功能但决定了后续效率的上限。2.1 开发语言与运行平台绝大多数大学生车队走两条路线STM32 裸机或 FreeRTOS 跑的 C 语言路线以及装有 Linux 系统的嵌入式控制器比如 NVIDIA Jetson、Up Board 或部分商业 VCU上的 C/Python 混合路线。两条路线各有拥趸。我的建议是如果团队从零起步、没有很强的嵌入式基础先用 C 语言 STM32 系控制器把整车算法骨架跑通这是最稳的路径。为什么三点理由C 语言是嵌入式控制器的母语CAN 外设驱动、ADC 采集、定时器中断这些底层资源几乎都是为 C 准备的资料最多、踩坑成本最低。整车控制算法的实时性要求非常高状态估算和故障保护的控制周期通常是 1ms 到 10msC 语言配合裸机中断或 RTOS 任务调度可以轻松满足。大学车队的人员流动大C 语言几乎人人会一点交接成本低。Python 适合做离线数据分析、标定工具、Simulink 模型验证但不适合直接跑在实时控制器里。如果你所在的车队已经具备一定的电子电气基础甚至有经验丰富的学长带也可以考虑基于 Linux 的控制器方案。它的优势是调试效率高——可以直接 SSH 上去看日志Python 写标定脚本很方便后续如果要上视觉感知甚至自动驾驶方向的算法整个技术栈可以平滑扩展。缺点是实时性相对难保证驱动层出问题排查难度大而且控制器成本高。2.2 代码管理从第一天就引入 Git这是我最想强调的一点。大学车队最大的痛不是代码写不出来而是代码在队员电脑里传来传去最后谁都不知道哪份是最新版本。从项目的第一天就把所有代码放进 Git 仓库至少能解决三个问题版本可追溯哪天改了什么、为什么改全部有记录出问题了一键回滚。并行开发互不干扰整车状态估算和扭矩分配策略完全可以让两个同学在两条分支上开发最后合并。代码备份托管到 GitHub 或 Gitee 的私有仓库队员电脑丢了也不怕。具体落地时建议建三个仓VCU_Algorithm整车算法主仓、VCU_Tools上位机工具、标定脚本、数据解析脚本、VCU_SimulationMATLAB/Simulink 或 Python 仿真模型。2.3 调试与监控工具链代码烧进控制器后怎么知道它跑得好不好这是第二个容易踩的坑。很多车队开发过程中不做数据监控整车一上电就两眼一抹黑出了问题只能靠猜。我的调试工具链是三层结构CAN 分析工具如 PCAN-View、USB-CAN 适配器 上位机软件直接看总线上每个报文的内容验证整车通信是否正常。车载日志记录在算法代码里做环形缓冲区把关键变量车速、扭矩请求、故障标志、BMS 数据周期性写入 SD 卡或 Flash。这个用于赛车跑起来之后的离线分析。上位机标定工具通过 CAN 或串口实时读写算法里的标定参数比如 PID 的 Kp、扭矩限制斜率、滤波系数。这样调参不用反复烧录固件效率提升非常明显。这套工具链第一版不需要做得很漂亮能用就行。很多车队喜欢先去写一个精美的大屏上位机界面结果核心算法还没影。我的建议是反过来先裸奔一个能显示关键变量和修改参数的简单工具等算法稳定了再回头把工具做精致。3. 整车算法软件架构设计分层、模块化与安全隔离上一节聊的是环境这一节进入正题算法代码里面到底怎么组织。很多车队的第一版算法是一个大 while 循环里写 1000 行 if-else把采集、处理、控制、故障判断全部揉在一起。这种写法在验证功能时跑得通一旦开始调试就容易出问题——改了这里那里开始不正常想单独测一下扭矩控制结果整个程序都要烧进去出了一个故障日志里什么都查不到。我在搭建这套算法时采用的是分层架构 模块化组件 安全路径隔离的设计思路这个思路从第一行代码开始贯穿始终。3.1 分层的思路整车算法从底层到顶层分成五层层级名称职责典型内容L0板级支持层单片机外设的初始化和底层驱动CAN 驱动、ADC 采集、GPIO、定时器、看门狗、SD 卡读写L1数据接入层对底层原始数据的封装和预处理CAN 报文解析、踏板信号滤波、速度信号处理、BMS 报文解包L2状态计算层车辆核心状态量的估算与计算车速估算、SOC 归一化、故障等级判定、车辆模式判定L3控制决策层根据状态量生成控制指令扭矩分配、能量回收策略、温度降功率策略、驾驶员意图解析L4执行输出层将控制指令输出到底层执行器扭矩请求发送、仪表显示、故障灯控制、蜂鸣器驱动分层的核心价值是依赖方向清晰。L0 不会去调用 L3 的函数L3 只能通过接口获取 L2 计算好的状态值。这样每一层都可以独立测试、独立调试、独立替换也可以让不同基础的同学并行开发。3.2 模块怎么切分在每一层内部我按功能独立、接口稳定的原则切成若干个模块模块之间通过头文件声明的接口函数通信不直接访问其他模块的内部变量。具体模块划分如下vcu_can.c/hCAN 报文收发、报文解包、报文超时监测vcu_signal.c/h模拟量和数字量信号的采集、滤波、故障诊断信号合理性判断vcu_state.c/h整车状态机上电自检、就绪、驱动、充电、故障等状态切换vcu_estimator.c/h车速估算、其他状态量的计算vcu_torque.c/h驾驶员扭矩请求生成扭矩仲裁和限制vcu_regen.c/h能量回收策略vcu_fault.c/h故障标志管理、故障处理、安全降级策略vcu_data_log.c/h数据记录、标定参数交互每个模块的对外接口控制在 5-10 个函数以内函数命名统一带模块前缀。比如扭矩模块对外就三个接口void vcu_torque_init(void); // 模块初始化 void vcu_torque_set_inputs(float pedal_pos, float brake_pos, float vehicle_speed); // 输入更新 float vcu_torque_get_request(void); // 获取最终扭矩请求为什么要严格控制接口因为接口就是契约。赛车队半年换一拨人如果模块之间乱耦合新接手的人根本不敢动代码。接口稳定了大家各自维护自己的模块出问题也好定位。3.3 安全路径隔离这是整个架构里最不能妥协的部分常规的功能逻辑走正常路径但涉及安全的功能高压互锁断开、BMS 严重故障、制动超时、绝缘故障必须走独立的安全路径。所谓独立指的是它的判定条件、处理流程和正常路径完全分离。具体做法是在 L0 层用独立中断或最高优先级任务处理急停信号和高压互锁信号不经过主循环。在 L1 层的 CAN 接收中断里对 BMS 的严重故障报文做快速判定一旦发现立即置位安全标志。在 L3 层的扭矩仲裁函数开头先查安全标志如果安全标志有效直接跳转到安全扭矩输出通常为 0不再执行正常扭矩计算。这样做的好处是即使正常路径的代码写出了bug只要安全路径没有被破坏赛车仍然可以被安全地限制在安全状态。其实这套思路也是从航天和功能安全标准里借鉴来的。大学生车队不必完全按 ISO 26262 流程走但**安全功能独立于功能逻辑**这个原则值得从第一版就烙进代码里。4. 关键功能模块的算法设计方案架构定好之后就是填充具体算法实现。这一节挑几个最核心、最体现赛车算法特色的模块详细展开。4.1 整车状态机设计整车状态机是整个算法的大脑主框架所有功能模块都围绕当前状态来决策。我的设计包含以下状态INIT上电初始化完成外设初始化、参数加载、自检。STANDBY待机自检通过等待启动信号。此状态下驱动扭矩强制为 0。READY_TO_DRIVE就绪驾驶员按下就绪按钮且满足所有安全条件后进入。电机控制器使能等待油门输入。DRIVING驱动检测到有效油门踏板输入后进入。正常扭矩请求生成。REGEN能量回收制动踏板踩下且满足回收条件时叠加回收扭矩。FAULT故障检测到任何安全等级为 fatal 的故障时立即进入扭矩输出强制为 0点亮故障灯。CHARGING充电状态高压上电且充电枪连接时进入禁止驱动。状态转移的触发条件要写清楚例如从 READY_TO_DRIVE 到 DRIVING 的条件是油门踏板开度 5% 且持续 50ms。为什么要设这个延时防止驾驶员踩油门瞬间的抖动脉冲误触发这在实车上非常常见。状态机实现上我采用查表法而不是一堆 if-elsetypedef struct { VCU_STATE current_state; VCU_STATE_EVENT event; VCU_STATE next_state; } state_transition_t; static const state_transition_t state_table[] { {VCU_STATE_INIT, VCU_EVENT_INIT_DONE, VCU_STATE_STANDBY}, {VCU_STATE_STANDBY, VCU_EVENT_START_PRESSED, VCU_STATE_READY_TO_DRIVE}, {VCU_STATE_READY_TO_DRIVE, VCU_EVENT_THROTTLE_PRESSED, VCU_STATE_DRIVING}, // ... 其他转移 };查表法的好处是状态转移关系一目了然新增状态或事件时只需要往表里加一行不需要改动原有逻辑而且代码执行时间是确定性的。4.2 车速估算比想象中更需要认真对待车速看起来是直接从轮速传感器读一下就行但实际并非如此。FSEC 赛车一般用两个后轮轮速传感器和一个车速传感器或 GPS各传感器都有自己的噪声和失效模式。差速时内外侧轮速不同、轮胎打滑时轮速不等于车速直接拿轮速当车速扭矩控制和能量回收策略都会受影响。我的车速估算方案是基于轮速的加权融合 合理性校验核心逻辑如下float vcu_estimate_vehicle_speed(void) { float wheel_speed_rear_left get_wheel_speed(REAR_LEFT); float wheel_speed_rear_right get_wheel_speed(REAR_RIGHT); float speed_est 0.0f; // 1. 轮速信号合理性检验 bool left_valid is_signal_valid(wheel_speed_rear_left); bool right_valid is_signal_valid(wheel_speed_rear_right); if (left_valid right_valid) { // 2. 正常情况下取两个后轮轮速的较小值驱动轮打滑时不至于高估车速 speed_est MIN(wheel_speed_rear_left, wheel_speed_rear_right); } else if (left_valid) { speed_est wheel_speed_rear_left; } else if (right_valid) { speed_est wheel_speed_rear_right; } else { // 3. 两路都失效进入安全降级模式 vcu_fault_set(VCU_FAULT_SPEED_SENSOR_LOSS); speed_est 0.0f; } // 4. 一阶低通滤波滤除轮速毛刺 static float speed_filtered 0.0f; const float filter_coeff 0.2f; // 通过标定调整 speed_filtered speed_filtered filter_coeff * (speed_est - speed_filtered); return speed_filtered; }这段代码里最核心的是取较小值策略在驱动工况如果内侧轮打滑轮速会大于车速取较小值可以避免把车速估得过大在制动工况如果车轮抱死轮速会小于车速这时较小值会低估车速。为处理这个问题需要在制动时引入参考车速逻辑用加速度积分做辅助估算这部分后续在实战篇展开。4.3 扭矩请求生成从踩多深走多快到踩多深受多少力驾驶员踩油门踏板本质是在表达我想要多大的加速意图算法要把它翻译成电机扭矩请求值。最基础的做法是查表踏板开度对应请求扭矩百分比再乘以当前允许的最大扭矩。但实际项目里我会在这个基础映射之上叠加三组处理变化率限制斜率限制防止驾驶员猛踩油门时扭矩瞬间拉满导致电机电流冲击过大或车辆失稳。限制值可以分正常模式和雨天/低附着模式两套标定。温度降功率曲线电机控制器和电机有各自的工作温度范围超过设定值后要按比例限制最大可用扭矩这叫降功率derating。这条策略在耐力赛中非常重要很多车队在比赛最后阶段因为电机过热被迫降速就是没有做好提前降功率。低电量保护电池 SOC 低到一定阈值时限制急加速时的峰值扭矩避免电池电压瞬间跌落触发欠压保护。扭矩请求的软件结构如下typedef struct { float pedal_position; // 0~1 float brake_position; // 0~1用于安全互锁 float vehicle_speed; // m/s float motor_temp; // ℃ float mosfet_temp; // ℃ float battery_soc; // 0~1 float battery_voltage; // V float battery_current; // A } VCU_TorqueInputs; typedef struct { float torque_request_raw; // 原始请求扭矩 Nm float torque_request_limited;// 限制后的扭矩 Nm uint8_t limit_source; // 限制了什么温度 / 电量 / 斜率 / 安全 } VCU_TorqueOutputs;计算流程是原始映射 → 斜率限制 → 最高可用扭矩仲裁 → 安全标志检查 → 最终输出。4.4 能量回收策略把每一焦耳都捡回来FSEC 耐力赛的胜负手往往不在直道极速而在能量管理。能量回收策略设计得好一圈下来能比对手多回收 10%-15% 的能量这在 22 公里耐力赛里的价值是决定性的。我的回收策略遵循三个原则回收优先级低于安全只要制动踏板踩下且车速高于阈值就进入回收。但如果检测到电池 SOC 超过 95%、电池温度过高或 BMS 禁止充电立即退出回收并切换为纯机械制动。回收扭矩随车速衰减低速时电机反电动势低回收效率差回收扭矩应该逐渐减小到 0避免造成顿挫感。与机械制动协调能量回收扭矩本身是一个制动力会叠加在机械制动之上。如果回收扭矩突然加入驾驶员会感觉车顿了一下。因此回收扭矩的切入要使用斜坡函数平滑建立。一个简单但有效的回收扭矩查表函数float vcu_regen_calc_torque(float brake_pos, float vehicle_speed, float soc) { // 回收允许条件 if (soc 0.95f || vehicle_speed 1.0f) { return 0.0f; } // 基础回收扭矩随制动踏板开度线性增加 float base_regen brake_pos * MAX_REGEN_TORQUE; // 低速衰减系数 float speed_factor vehicle_speed / REGEN_FULL_SPEED; if (speed_factor 1.0f) speed_factor 1.0f; // 高SOC降额 float soc_factor 1.0f; if (soc 0.85f) { soc_factor (1.0f - soc) / 0.15f; } return base_regen * speed_factor * soc_factor; }实际标定时要注意 MAX_REGEN_TORQUE 不能设得过大。回收扭矩过大会导致后轮在低附着路面上突然抱死车尾瞬间甩起来——在赛场上这是高风险事故。我的经验是先把 MAX_REGEN_TORQUE 设为电机峰值扭矩的 20%再逐步往上调每次增加 5%并配合实车制动测试确认稳定性。5. 从代码写完到车上能跑测试与标定的关键路径代码写完只是开始真正决定算法能否上车的是接下来的测试与标定环节。很多车队在这一步翻了大跟头。5.1 测试层级规划我习惯把测试分成四级单元测试在 PC 上对每个模块的核心逻辑做输入输出验证。比如扭矩查表函数、状态机转移逻辑、SOC 降额计算都是纯数学逻辑完全可以脱离硬件测试。C 语言可以用 Unity 框架或简单写个 main 函数来跑。硬件在环测试HIL把算法烧进真实的 VCU 控制器通过 CAN 报文模拟器向 VCU 发送模拟的传感器数据和 BMS 数据验证算法在真实硬件环境下的行为。这个阶段不需要整车只需要控制器、电源、CAN 工具和一台上位机。HIL 测试能抓住大量时序问题比如中断优先级冲突、任务超时。台架测试把电机和电机控制器接上通过手动或简单机械结构模拟负载验证扭矩请求到电机输出的通路是否正常、电流是否在预期范围内。整车测试从低速直线起步开始逐步扩展到制动回收、蛇形绕桩、动态工况。大部分车队的问题是跳级代码写完直接上整车一个故障接着一个故障既分不清是算法问题还是接线问题也分不清是控制问题还是机械问题。分级测试虽然前期投入大但越到后期越省时间。5.2 一个最容易忽视的坑CAN 报文超时处理CAN 通信有一个典型故障某个报文因为线束松动、节点掉线等原因突然不发了。如果算法里没有超时监测控制器会一直沿用最后一帧的数据这在高压系统里极其危险。我的解决办法在 L1 数据接入层统一做报文超时监测每个关键报文尤其是 BMS 状态报文分配一个新鲜度计数器。接收中断里每收到一帧就清零主循环里周期性对计数器加一。如果某个报文超过设定时间比如 100ms没有更新就置位对应故障标志并触发降级逻辑。void vcu_can_monitor_timeout(void) { for (int i 0; i VCU_CAN_MSG_COUNT; i) { if (can_frame_age[i] CAN_TIMEOUT_COUNTER) { can_frame_age[i]; if (can_frame_age[i] CAN_TIMEOUT_COUNTER) { vcu_fault_set(can_frame_fault_map[i]); can_frame_ok[i] false; } } } }这个机制必须在 HIL 阶段就测到位人为拔掉某路 CAN 节点观察算法是否能在规定时间内进入安全状态。5.3 标定参数管理的艺术算法里会有一堆可调参数滤波系数、扭矩斜率、温度降额阈值、状态机延时等等。这些参数如果全部硬编码在源代码里每次调参都要重新编译烧录效率极低而且很容易调乱了忘了原来在哪。我的做法是定义一个标定参数结构体集中管理所有可调参数。参数保存一段独立的 Flash 区域程序启动时加载同时通过 CAN 或串口提供在线读写接口上位机工具可以直接修改参数并写回 Flash。typedef struct { float pedal_filter_coeff; // 油门踏板滤波系数 float brake_filter_coeff; // 制动踏板滤波系数 float torque_slope_up; // 扭矩上升斜率 float torque_slope_down; // 扭矩下降斜率 float max_regen_torque; // 最大回收扭矩 float motor_temp_derate_start; // 电机降功率起始温度 float motor_temp_derate_end; // 电机完全降功率温度 } VCU_CalibParams; VCU_CalibParams vcu_calib_params;参数集要加上版本号和 CRC 校验防止数据损坏时算法用了垃圾参数。这个系列的第一篇先讲到这里。架构和基础模块搭好之后后面几篇会分别展开状态估算的详细推导、扭矩仲裁的安全逻辑、能量回收的精细策略、以及 HIL 台架的搭建和标定流程。以我的经验第一版代码可能不够完美但只要架构清晰、测试路径明确后面每个迭代都会越走越快。