智能车开发实战：从硬件搭建到STM32底层调参全解析

从硬件折腾到底层调参：致敬我为智能车拼过的每一个日夜

如果你也是那种在实验室焊板子到凌晨、为一个参数反复烧录几百次的人，这篇文章应该能看懂。

之前在做智能车项目时，我一直在想，等比赛结束、等车稳定跑完一圈，要写点东西记录这段经历。不是因为成绩多好，而是因为整个过程里踩过的坑、查过的寄存器、调过的PID、换过的驱动板，太多值得沉淀的东西。网上关于智能车的资料很多，但零散，很多关键细节要靠自己试错才能发现。

所以这篇文章不聊虚的，单纯从一个“过来人”的角度，把智能车从硬件搭建、底层驱动、传感器采集到闭环控制的完整路径拆开讲一遍。想入门智能车竞赛的初学者，或者正在为不稳定循迹、无法收敛PID而发愁的朋友，可以直接对照文章一步步排查。有嵌入式开发基础的，也可以跳过前面的基础概念，重点看核心代码和排错思路。

这篇文章的主体内容，就是基于我那段时间反复验证过的方案整理而来，完整覆盖环境准备、硬件选型、代码实现、调参技巧和常见问题。哪怕你手里的车是另一种型号，只要理解了这套框架，迁移起来也不会太费力。

1. 智能车到底在做什么：先看清整车架构

很多新手拿到套件第一反应是“先烧个例程看看”。这个思路不能说错，但如果完全不知道整套系统是怎么协作的，后面调车会非常痛苦。

1.1 智能车的本质：一个移动的嵌入式系统

智能车说白了就是把“感知—决策—执行”三个环节跑通的移动嵌入式系统。摄像头负责感知赛道信息，也就是看线、看斑马线、看障碍物；主控芯片把摄像头传回来的画面数据换算成“车现在偏了多少、要转多少度”；然后通过电机驱动模块控制左右轮转速差，让车回到赛道中线。

整个过程每秒钟要重复几十次甚至上百次，这就是控制频率。控制频率越高，车的响应越快，但前提是传感器数据拿到得够快、算法足够简练，否则主控忙不过来。

很多人会把智能车和普通的遥控车混在一起。遥控车是人在闭环里，你用眼睛判断方向，用手柄发指令。智能车则是把“人”的角色拿掉，让程序自己完成判断。这个区别很重要，因为它决定了代码结构：你必须写清楚传感器读取、偏差计算、PID输出、电机设定的完整循环。

1.2 常见比赛场景与功能需求

不管参加的是智能汽车竞赛、电子设计竞赛还是学校里的创新项目，主流赛题都会涉及下面几类功能：

• 循迹：识别赛道中线或边界，这是最基础也是最核心的功能。
• 弯道与十字路口处理：要求车辆在弯道减速、在十字交叉口不误判。
• 障碍物检测与避让：通过摄像头或超声波传感器识别障碍，规划绕行路径。
• 坡道、斑马线等特殊元素：需要根据特定图像特征做状态切换。
• 速度闭环与转向闭环：用编码器测速、陀螺仪测姿态，让车稳定可控。

所以你会发现，智能车不是单纯写一个“找线”的程序，而是要写一整套状态机。

1.3 整车系统划分

在搭建项目之前，先把系统分成下面几个模块，后续开发和排错都会清晰很多：

这种模块化思维不只用于智能车，任何嵌入式项目都适用。后期如果某个模块出了问题，可以直接在对应的子系统中排查，而不是面对一整坨不可拆分的代码。

2. 环境准备与硬件选型：先把工具链备齐

智能车项目的硬件种类很多，不同的比赛、不同的预算、不同的规则会影响最终选型。但整体框架是差不多的，下面列出我实际用过的方案，可以作为参考。

2.1 硬件清单参考

如果还在入门阶段，优先选择资料多、社区活跃的硬件。硬件本身不是越贵越好，能够让你把“感知—决策—执行”跑通才是关键。

2.2 软件工具链

开发环境建议搭建如下：

• Keil MDK（STM32 开发）：用于编写主控程序。
• STM32CubeMX：用于初始化时钟、GPIO、定时器、串口等外设。
• OpenMV IDE（如果摄像头选了 OpenMV）：用于调试视觉脚本。
• 串口调试助手：用于查看调试数据。
• Git：用于保存代码版本，参数大调整时能快速回滚。

版本方面需要根据你自己手里的开发板、库版本和IDE版本来调整。STM32项目可以使用标准外设库，也可以用HAL库，下面的示例以HAL库为主，这是因为CubeMX生成的代码可读性好、新手更容易上手，而且后续换芯片时迁移方便。本文重点演示配置思路，具体外设型号不一样时，对应的引脚和时钟树会不同。

2.3 项目目录结构

写代码之前，建议把整个项目按模块分目录：

CarProject/ ├── Core/ │ ├── Inc/ │ └── Src/ ├── Drivers/ │ └── stm32f1xx_hal_driver/ ├── MyApp/ │ ├── pid.c / pid.h │ ├── motor.c / motor.h │ ├── encoder.c / encoder.h │ ├── imu.c / imu.h │ └── track.c / track.h └── MDK-ARM/

如果一开始就不分层，等到功能多了，main.c 文件会膨胀到几千行，找一个小逻辑都要滚动半天。按模块拆开之后，每个文件只负责一件事，无论是调试还是代码审查都会轻松很多。

3. 核心模块拆解：每一行代码都要知道为什么

这一部分是整篇文章的重点。我不只是贴代码，更重要的是把每个模块为什么这样设计、参数如何选取、容易出什么问题讲清楚。

3.1 电源树设计：稳定是一切的前提

智能车最常见的故障不是程序跑飞，而是电压不稳导致传感器数据异常。摄像头画面闪动、电机转速忽快忽慢、单片机频繁复位，大概率都是电源没做好。

常见的供电思路是：

• 电池电压先进入总开关和保险丝。
• 电机驱动直接接电池正极，因为电机瞬间启动电流很大，如果和主控共用一路供电，会把主控电压拉垮。
• 主控、摄像头、传感器通过降压模块独立供电，推荐使用低压差线性稳压器或DC-DC降压模块，输出5V和3.3V两个电压等级。
• 所有模块的GND必须共地，否则通信信号没有参考电位，I2C和串口都会出现随机错误。

很多新手一上来就全用杜邦线连，接触不良的时候查半天查不出来。建议电机驱动与电池之间用粗硅胶线，其他信号线用杜邦线时也要插紧，长期调试最好做一个转接板。

3.2 电机驱动与PWM控制

直流电机的速度是通过PWM波来控制平均电压实现的。占空比越大，平均电压越大，转速越高。主控输出的PWM信号本身不能直接驱动电机，必须经过电机驱动模块放大。

在CubeMX里，定时器可以输出多路PWM。例如使用TIM2的CH1和CH2分别控制左右电机，TIM3的编码器模式读编码器。

电机控制核心代码片段，需要放在MyApp/motor.c中：

/* 文件路径：MyApp/motor.c */ #include "motor.h" #include "tim.h" void Motor_SetSpeed(Motor_TypeDef *motor, int16_t speed) { if (speed > 0) { // 正转：IN1=1, IN2=0 HAL_GPIO_WritePin(motor->in1_port, motor->in1_pin, GPIO_PIN_SET); HAL_GPIO_WritePin(motor->in2_port, motor->in2_pin, GPIO_PIN_RESET); } else if (speed < 0) { // 反转：IN1=0, IN2=1 HAL_GPIO_WritePin(motor->in1_port, motor->in1_pin, GPIO_PIN_RESET); HAL_GPIO_WritePin(motor->in2_port, motor->in2_pin, GPIO_PIN_SET); speed = -speed; } else { // 停止：IN1=0, IN2=0 HAL_GPIO_WritePin(motor->in1_port, motor->in1_pin, GPIO_PIN_RESET); HAL_GPIO_WritePin(motor->in2_port, motor->in2_pin, GPIO_PIN_RESET); } if (speed > 1000) { speed = 1000; } __HAL_TIM_SET_COMPARE(motor->pwm_tim, motor->pwm_ch, speed); }

这里有几个关键点：

• 占空比上限为什么要限制？因为电机和驱动芯片都有一个最大占空比，超过之后电流过大，可能烧驱动。工程上通常用1000表示100%占空比，具体数值取决于定时器重载值。
• 设置正反转的时候要注意先改变方向，再输出PWM。如果顺序反了，方向切换瞬间会出现短暂反向电流，影响寿命。

3.3 编码器测速：速度闭环的眼睛

如果只开环给占空比，车在电池电压下降之后速度就会变慢。为了稳定速度，必须引入编码器，把实际转速反馈给主控。

编码器一般接在电机尾部，输出两路正交方波A、B。把这两路信号接到STM32的定时器编码器模式引脚上，定时器硬件就能自动完成倍频和计数，不需要CPU中断去数脉冲。

CubeMX配置思路：

• 选择定时器的Encoder Mode。
• 配置A、B引脚为复用功能开漏或推挽，依据板子原理图而定。
• 定时器重载值设置得大一点，避免计数溢出。

读取编码器计数值的代码如下：

/* 文件路径：MyApp/encoder.c */ #include "encoder.h" #include "tim.h" int16_t Encoder_GetCount(TIM_HandleTypeDef *htim) { int16_t count = (int16_t)__HAL_TIM_GET_COUNTER(htim); __HAL_TIM_SET_COUNTER(htim, 0); return count; }

注意这里一定要读完清零。否则下一次读的时候数值会一直累加，PID反馈就会出问题。在中断里调用或者在主循环里定时调用都可以，但周期必须固定，这样才能把脉冲数换算成真实速度。

3.4 陀螺仪姿态：让车知道自己是正还是歪

MPU6050是智能车里用得最多的一款六轴传感器，包含三轴加速度计和三轴陀螺仪。它通过I2C接口和主控通信。

在智能车场景里，我们主要关心的是车的航向角和角速度。航向角可以通过陀螺仪积分得到，但陀螺仪存在温漂，长期积分会飘走；加速度计可以测倾角，但动态时噪声大。工程上常用互补滤波或卡尔曼滤波来融合两路数据。

读取MPU6050原始数据的核心代码：

/* 文件路径：MyApp/imu.c */ #include "imu.h" #include "i2c.h" #define MPU6050_ADDR 0xD0 #define PWR_MGMT_1_REG 0x6B #define ACCEL_XOUT_H_REG 0x3B #define GYRO_XOUT_H_REG 0x43 uint8_t imu_init(void) { uint8_t data = 0x00; // 唤醒MPU6050 HAL_I2C_Mem_Write(&hi2c1, MPU6050_ADDR, PWR_MGMT_1_REG, 1, &data, 1, 100); return 0; } void imu_read_raw(IMU_DataTypeDef *imu) { uint8_t buf[14]; HAL_I2C_Mem_Read(&hi2c1, MPU6050_ADDR, ACCEL_XOUT_H_REG, 1, buf, 14, 100); imu->accel_x = (int16_t)((buf[0] << 8) | buf[1]); imu->accel_y = (int16_t)((buf[2] << 8) | buf[3]); imu->accel_z = (int16_t)((buf[4] << 8) | buf[5]); imu->temp = (int16_t)((buf[6] << 8) | buf[7]); imu->gyro_x = (int16_t)((buf[8] << 8) | buf[9]); imu->gyro_y = (int16_t)((buf[10] << 8) | buf[11]); imu->gyro_z = (int16_t)((buf[12] << 8) | buf[13]); }

MPU6050的寄存器地址是公开且稳定的，所以上面的地址可以直接用。需要注意的是，I2C读取时大部分MPU6050器件地址是0xD0，但有些模组上的地址引脚电平不同，实际地址会变成0xD2。如果初始化时读不到数据，先检查地址。

3.5 摄像头循迹：把图像变成偏差

摄像头部分我推荐用OpenMV这类视觉模块。它自己带处理器，可以直接跑图像处理脚本，然后通过串口把“偏差值”发给STM32。这样做的好处是主控不需要处理大量图像数据，逻辑更简单。

OpenMV里的核心思路是阈值分割：把赛道中要寻的线（比如白色线、黑色线或红色引导线）从背景里分离出来，然后寻找色块的质心，算出质心和画面中心线的偏差。

下面是OpenMV端的一个循迹脚本示例：

# 文件路径：openmv/track.py import sensor import image import time from machine import UART # 初始化摄像头 sensor.reset() sensor.set_pixformat(sensor.RGB565) sensor.set_framesize(sensor.QQVGA) sensor.skip_frames(10) # 串口初始化 uart = UART(3, 115200) uart.init(115200) red_threshold = (80, 100, 20, 80, 20, 80) # 根据实际赛道颜色调整 while True: img = sensor.snapshot() blobs = img.find_blobs([red_threshold], pixels_threshold=200, area_threshold=200) cx = 80 # 画面中心横坐标，QQVGA宽度160，中心为80 if blobs: largest_blob = max(blobs, key=lambda b: b.pixels()) cx = largest_blob.cx() img.draw_cross(largest_blob.cx(), largest_blob.cy()) # 偏差 = 目标横坐标 - 画面中心 error = cx - 80 # 发送格式：e:数值\n uart.write("e:%d\n" % error) time.sleep_ms(10)

这个脚本的思路是：每10ms跑一帧，找到目标色块，算出色块横坐标和画面中心的差值，通过串口发出去。STM32只需要解析串口数据，拿到error之后送给转向PID。

阈值参数要根据实际赛道光照来调，不同光线下的红色阈值差别很大。建议在OpenMV IDE里直接调阈值工具，把背景优化到“只有赛道引导线被选中”为止。

3.6 PID闭环控制：让车稳定下来的关键

PID是智能车项目的灵魂。比例项P让控制量随偏差增大而增大；积分项I消除稳态误差；微分项D抑制超调。实际调试中，P给车“方向感”，D给车“阻尼感”，I一般用得少甚至不用。

转向或速度控制的核心代码：

/* 文件路径：MyApp/pid.c */ #include "pid.h" void PID_Init(PID_TypeDef *pid, float kp, float ki, float kd, float limit) { pid->kp = kp; pid->ki = ki; pid->kd = kd; pid->limit = limit; pid->integral = 0.0f; pid->last_error = 0.0f; } float PID_Calculate(PID_TypeDef *pid, float target, float current) { float error = target - current; pid->integral += error; float output = pid->kp * error + pid->ki * pid->integral + pid->kd * (error - pid->last_error); pid->last_error = error; if (output > pid->limit) { output = pid->limit; pid->integral -= error; // 抗积分饱和 } else if (output < -pid->limit) { output = -pid->limit; pid->integral -= error; } return output; }

两个容易踩坑的地方：

• 积分饱和：如果车一直被堵住，误差持续为正，积分项会不断增大，等堵住的东西移开之后，车会猛冲出去。上面的抗积分饱和处理是差一点的关键。
• 微分项放大噪声：如果只用最近一次误差做微分，传感器噪声会很明显，车会抖。工程上常用“一阶低通滤波”来平滑微分项。

D项输出 = 低通系数 * 本次D输出 + (1 - 低通系数) * 上次D输出

4. 完整实战案例：一辆能稳定跑圈的循迹小车

前面是模块化讲解，这一节串起来做一个“摄像头循迹 + 速度闭环”的完整小项目。不需要复杂的赛道元素，重点是把链路跑通，验证整套方案。

4.1 创建项目结构

先用STM32CubeMX新建工程，选择自己的芯片型号。配置好时钟树、SWD调试口、调试串口（USART1）、电机PWM定时器（TIM2）、编码器定时器（TIM3）、I2C（I2C1用于MPU6050）。

创建完成后，在工程目录下新建MyApp文件夹，并添加下面这些文件：

• pid.c / pid.h
• motor.c / motor.h
• encoder.c / encoder.h
• imu.c / imu.h
• track.c / track.h

4.2 添加依赖与头文件路径

在Keil里，把MyApp文件夹加入Include Path。工程里已有的HAL驱动文件保持不变。如果要使用printf重定向到串口，需要包含stdio.h并重写fputc()。

4.3 编写主循环代码

主循环不能只写一个while(1)然后把所有事堆进去。我的做法是把任务按时间片拆开：串口数据处理、摄像头数据解析、速度控制、转向控制，各自有固定的执行周期。

main.c中的核心逻辑：

/* 文件路径：Core/Src/main.c（核心片段） */ #include "main.h" #include "pid.h" #include "motor.h" #include "encoder.h" #include "imu.h" #include "track.h" PID_TypeDef speed_pid; PID_TypeDef steer_pid; volatile int16_t track_error = 0; int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_TIM_Init(); MX_I2C1_Init(); MX_USART1_UART_Init(); PID_Init(&speed_pid, 0.6f, 0.0f, 0.1f, 500.0f); PID_Init(&steer_pid, 1.2f, 0.0f, 0.4f, 400.0f); // 循环等待串口数据 while (1) { // 1. 解析来自OpenMV的偏差 Track_ParseUartData(); // 2. 读取编码器速度 int16_t left_speed = Encoder_GetCount(&htim3); int16_t right_speed = Encoder_GetCount(&htim4); // 3. 速度PID：目标速度由赛道元素决定 float target_speed = 150.0f; float speed_output = PID_Calculate(&speed_pid, target_speed, left_speed); // 4. 转向PID：目标偏差为0 float steer_output = PID_Calculate(&steer_pid, 0.0f, (float)track_error); // 5. 输出到电机 Motor_SetSpeed(&left_motor, (int16_t)(speed_output - steer_output)); Motor_SetSpeed(&right_motor, (int16_t)(speed_output + steer_output)); HAL_Delay(10); } }

这只是一个演示骨架。实际项目里目标速度要根据赛道状态动态切换，比如入弯减速、出弯加速。转向输出叠加到左右电机差速上，是智能车普遍采用的差速转向方案。

4.4 串口数据解析

OpenMV发过来的数据格式是e:数值\n，STM32解析函数：

/* 文件路径：MyApp/track.c */ #include "track.h" #include "usart.h" static uint8_t rx_buf[64]; static uint8_t rx_len = 0; volatile int16_t track_error = 0; void Track_ParseUartData(void) { // 实际使用时可以把HAL_UART_Receive_IT放到中断中 // 这里简化：假设已经收到完整一行字符串 if (rx_len > 3 && rx_buf[0] == 'e' && rx_buf[1] == ':') { track_error = (int16_t)atoi((char *)&rx_buf[2]); rx_len = 0; } } void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART1) { // 判断是否收到换行符，收满一行后置位 static uint8_t index = 0; if (rx_buf[index] == '\n') { rx_len = index; index = 0; } else { index++; } HAL_UART_Receive_IT(&huart1, &rx_buf[index], 1); } }

串口接收的思路是一次接收一个字节，把数据暂存在数组里，收到换行符之后认为这一帧数据完整，再统一解析。这样可以避免在中断里做复杂计算，保证主循环的数据一致性。

4.5 运行与验证

代码烧录之后，验证步骤建议按下面顺序做：

1. 先不装车模，只给主控上电，确认OpenMV的UART有数据输出，串口助手能看到e:xx格式的连续数据。
2. 用一个串口助手查看STM32回传的编码器数值，用手转动轮子，看数值是否变化、方向是否正确。
3. 只开速度环：把车架起来，让轮子悬空，给定目标速度，观察转速是否稳定。
4. 只开转向环：把车架起来，在摄像头前放一条赛道线，左右移动线，观察两个轮子的差速是否跟随线的位置变化。
5. 全部整合之后，放到实际赛道上低速跑，逐步调高速度。

每步都验证通过，再往下走。如果哪一步不正常，不要继续往下调，先回头解决当前问题。

5. 常见问题与排查思路

智能车调试中最大的成本是“排查问题”的时间。这里把常见现象、原因和解决方案整理出来，遇到问题可以对着查。

如果你遇到的是编译错误或链接错误，先确认CubeMX生成的代码和你手写的代码之间没有重复定义函数。用//注释掉冲突部分，比反复改工程结构更快。

6. 最佳实践与工程建议：从“能跑”到“好调”

能跑起来的小车很多，好调好改的小车才真正体现工程能力。以下几个建议是实际项目中体会最深的。

6.1 把参数集中管理，不要散落各处

PID参数、目标速度、阈值、串口波特率这类常量，全部放到一个config.h文件里集中定义。这样调车时不需要打开好几个文件翻找，改起来效率高很多。

/* 文件路径：MyApp/config.h */ #ifndef __CONFIG_H #define __CONFIG_H #define TARGET_SPEED_NORMAL 150.0f #define TARGET_SPEED_CORNER 90.0f #define STEER_PID_KP 1.2f #define STEER_PID_KD 0.4f #define SPEED_PID_KP 0.6f #define SPEED_PID_KD 0.1f #endif

6.2 善用日志与上位机

不要只靠小车跑起来之后肉眼观察。把关键变量（目标偏差、实际偏差、PID输出、左轮速度、右轮速度）通过串口打印出来，用串口上位机或高级调试终端画曲线，效果完全不同。你能直接看到PID有没有震荡、饱和、延迟，这些靠“看车走不走得直”很难判断。

6.3 版本管理是硬道理

智能车调参时，经常出现“今天调得很好，第二天突然不行了”的情况。可能是电池电压变了，可能是光线变了，也可能是上一版本的代码覆盖了当前版本。用Git管理代码，每次跑出好成绩就把参数和代码打一个Tag，记录赛道环境、电池电压、轮胎磨损情况。这样任何改动都能回溯。

6.4 硬件保护不可忽视

接线时在电源入口加保险丝和反接保护二极管，是成本最低的保护措施。电机驱动模块的使能引脚、PWM输入引脚不要直接接到单片机IO口上，如果驱动模块烧了，高压可能倒灌进主控芯片。可以使用隔离模块或在主控和驱动之间加缓冲。

6.5 坚持最小系统原则

排错时最快的方法是减法：先把所有传感器断开，只保留电源和主控，确认最小系统正常；然后逐个加回传感器，每加一个都测试一下通信和数据。这套方法在嵌入式系统里同样适用。很多时候问题看起来复杂，但其实是某些模块之间相互干扰。

7. 最后想说的一些话

写这篇文章，不只是在整理技术方案，也是在纪念那些反复调车的日子。

智能车项目说难不难，说简单也绝对不简单。从一片空白开始，画板子、焊电路、看文档、调PID、跑赛道，每一步都需要耐心。真正经历过才会明白，比赛跑完那几秒钟的成绩，背后是无数个深夜和几十次方案的推翻重来。

我希望后来者不要被“参数怎么调都跑不好”劝退。这不是你一个人遇到的情况，几乎每个人都要走过这段路。把问题拆开，一步步验证，记录每次改动的效果，很多困难都能被慢慢磨掉。

如果这篇文章能帮你少走一点弯路，或者让你在调车遇到瓶颈时多一个排查思路，那这段经历就没有白写。智能车的终点不是成绩和奖状，而是你在这个过程中锻炼出来的动手能力、排错思维和坚持到底的性子。

下一阶段，你可以继续深入学习卡尔曼滤波实现更平滑的姿态解算，或者把视觉算法迁移到K210平台上做更快的目标检测，还可以尝试加入RTOS让任务调度更可靠。这些方向都是智能车进阶路上的自然延伸。

祝每一辆智能车都能跑出自己满意的成绩，也祝每一个为智能车拼过的人，都能在这段旅程里找到属于自己的成长和收获。如果你在调试过程中有其他问题，欢迎在评论区留言，一起交流。