企业官网建设流程全解析

赛车算法？这题目一听就是大学生方程式圈子里的人才会碰的东西。我当初刚接电车队的算法负责人时，也是一脸懵，从零开始啃，踩了无数坑才把整车控制那套东西跑通。这篇文章就把我这几年的心得整理出来，给后面入队的学弟学妹们一条相对顺的路。

先交代一下背景：我们车队是电动的，参加的是中国大学生电动方程式大赛（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的调参过程。如果你们车队正在卡在某一环节，也欢迎把具体问题抛到评论里，我看到会挑有代表性的在后续文章里拆开讲。