电动自行车的核心在于电机控制系统,这直接决定了车辆的加速性能、续航能力和骑行体验。一套完整的电机控制方案需要兼顾硬件设计、软件算法和实际路况适配三大维度。
目前主流方案采用无刷直流电机(BLDC)搭配FOC(磁场定向控制)算法,这种组合在效率、噪音和扭矩输出上达到了较好的平衡点。我在多个量产项目中验证过,相比传统的方波控制,FOC能使续航提升15%-20%,特别适合需要长距离通勤的场景。
关键提示:选择控制方案时首先要明确电机类型。有霍尔传感器的方案开发门槛较低,而无感方案(通过反电动势检测转子位置)虽然减少了故障点,但对算法要求更高。
典型硬件架构包含这几个核心模块:
我在实际布线时有个经验:MOSFET栅极驱动线要尽量短(<3cm),否则开关损耗会导致管子异常发热。曾有个项目因此烧毁了整整一批驱动板,后来用示波器抓取栅极波形才发现振铃现象严重。
从简单到复杂,电机控制算法大致分三个阶段:
c复制// FOC算法核心代码片段
void FOC_Control(void) {
ClarkeTransform(Ia, Ib, &I_alpha, &I_beta); // 三相转两相
ParkTransform(I_alpha, I_beta, Theta, &Id, &Iq); // 旋转坐标系变换
PID_Regulator(&Id, &Iq); // 电流环调节
InverseParkTransform(Vd, Vq, Theta, &Valpha, &Vbeta); // 反变换
SVM_Generate(Valpha, Vbeta); // 空间矢量调制
}
实测数据显示,在同等电池容量下,FOC算法比传统方波控制多跑8-12公里。但要注意:算法越复杂,对MCU算力要求越高。STM32F103跑基础FOC勉强够用,若要加入弱磁控制等高级功能,就得换Cortex-M4内核的芯片了。
好的电机控制代码应该像洋葱一样分层清晰:
这种架构的最大好处是移植方便。去年有个项目要从STM32换成GD32,我们只重写了HAL层,上两层代码复用率超过90%。
避坑指南:千万不要在中断服务程序里做浮点运算!曾经有个工程师在ADC中断里直接计算FOC,导致控制周期从设计的100us飙升到300us,电机运行时嗡嗡作响。后来改用Q15格式定点运算才解决问题。
油门信号处理:
c复制#define FILTER_COEF 0.1f // 一阶滤波系数
float Throttle_Filter(float raw) {
static float filtered = 0;
filtered = FILTER_COEF * raw + (1-FILTER_COEF) * filtered;
return filtered;
}
这个简单的低通滤波能有效消除手柄抖动带来的转速波动。系数取值很关键,太小会导致响应迟钝,太大则滤波效果差。经过多次路试,0.1-0.3这个范围比较合适。
电流环PID调节:
c复制typedef struct {
float Kp, Ki, Kd;
float integral_max;
float output_max;
} PID_Params;
float PID_Calculate(PID_Params *p, float err) {
static float integral = 0;
integral += err;
integral = constrain(integral, -p->integral_max, p->integral_max);
return constrain(err*p->Kp + integral*p->Ki, -p->output_max, p->output_max);
}
电流环是控制精度的关键,这里有几个调参心得:
电动自行车有几种典型工作模式:
mermaid复制stateDiagram
[*] --> IDLE
IDLE --> RUNNING: 油门信号>阈值
RUNNING --> BRAKING: 刹车信号触发
BRAKING --> IDLE: 车速<1km/h
RUNNING --> ERROR: 过流/过热
ERROR --> IDLE: 故障清除
实际编码时建议用枚举实现:
c复制typedef enum {
STATE_IDLE,
STATE_RUNNING,
STATE_BRAKING,
STATE_ERROR
} SystemState;
void StateMachine_Update(void) {
static SystemState state = STATE_IDLE;
switch(state) {
case STATE_IDLE:
if(throttle > THRESHOLD) state = STATE_RUNNING;
break;
case STATE_RUNNING:
if(brake_active) state = STATE_BRAKING;
else if(fault_detected) state = STATE_ERROR;
break;
// 其他状态处理...
}
}
通过示波器抓取相电流波形时,我发现两个优化点:
实测数据对比:
| 参数 | 优化前 | 优化后 |
|---|---|---|
| 整机效率 | 82% | 88% |
| MOSFET温升 | 65℃ | 48℃ |
| 续航里程 | 45km | 52km |
可靠的保护电路是量产方案的必备项,这些保护必须硬件实现:
软件层面还要加入:
曾有个案例:用户在下雨天骑行,控制器进水导致MOSFET短路。由于硬件过流保护响应够快(<5us),仅烧毁了驱动芯片,主控和电池都完好无损。这比纯软件保护(通常要100us以上)安全得多。
这些工具能极大提升开发效率:
有个小技巧:用CAN总线输出调试数据。相比串口,CAN总线能同时传输多组数据且不易受干扰。我们自定义了一个简单协议:
code复制ID[0:3] | DATA[0:7]
0x100 | 电机转速(RPM)
0x101 | Iq/Id电流(0.1A分辨率)
0x102 | MOSFET温度(℃)
量产前必须通过这些测试项:
python复制def test_emergency_stop():
set_throttle(100%)
wait(2s)
trigger_brake()
assert motor_rpm() == 0 within 500ms
def test_overcurrent():
gradually_increase_current()
assert system_shutdown_when(current > 30A)
建议用Robot Framework搭建自动化测试台,可以模拟各种异常工况:
去年我们通过自动化测试发现了PCB layout的一个隐患:大电流回路面积太大导致EMC测试失败。后来重新优化了功率地走线,省去了后期返工的巨额成本。
可能原因及解决方案:
有个经典案例:某批次电机低速时抖动严重。最后发现是霍尔传感器安装角度偏差了15度,通过软件补偿相位角后问题解决。
按照这个流程排查:
遇到过最棘手的案例是电机能启动但随机停转。最终发现是MCU的看门狗复位了,原因是电流环计算超时。通过优化算法和调整看门狗时间解决了问题。
不同地区对电动自行车的法规要求差异很大:
认证测试时要特别注意:
有个经验教训:出口欧洲的车型最初没做CE认证,结果在海关被整批退回。后来我们专门成立了认证团队,提前半年开始准备测试样品,节省了大量时间成本。