1. 项目缘起与核心挑战看到这个标题很多参加过电赛或者正在准备嵌入式AI项目的朋友应该会心一笑。2021年全国大学生电子设计竞赛的F题要求设计一个“智能送药小车”其中有一个核心的识别任务就是需要小车在行驶过程中识别出地面上随机放置的数字标识比如1、2、3等并根据数字执行不同的动作。这个任务听起来简单但在当年的赛场上却让不少队伍“折戟沉沙”。难点在哪它要求识别系统必须同时满足实时性、高精度、低功耗和强鲁棒性。在资源受限的嵌入式平台上跑一个能应对复杂光照、角度畸变、部分遮挡的视觉识别模型本身就是一场硬仗。我当时带的队伍核心方案就是标题里提到的“Jetson Nano STM32F4”双核架构。Jetson Nano负责“看”和“想”——运行深度学习模型进行数字识别STM32F4负责“动”和“控”——处理传感器数据、执行电机控制、决策路径。这个组合在当时算是“高配”但如何让两者高效协同把识别准确率做到99%以上并且保证从图像采集到结果输出控制在百毫秒级里面全是细节和“坑”。网上能找到的源码和数据集往往比较零散或者只解决了“跑通”的问题离“赛用级”的稳定和高效还有距离。今天我就结合我们当时的实战代码和自建数据集把这套方案从选型、部署、优化到联调的完整链条拆解清楚希望能给后来者一个可以直接“抄作业”的参考。2. 硬件平台选型与架构设计逻辑为什么是Jetson Nano加STM32F4这个组合不是拍脑袋定的而是基于赛题要求和技术边界反复权衡的结果。2.1 主控大脑Jetson Nano的不可替代性首先看识别核心。数字识别尤其是需要应对赛场多变环境光线明暗、数字倾斜、轻微污损传统图像处理算法如模板匹配、特征点检测的鲁棒性很难保证。卷积神经网络CNN是更优解。但CNN模型需要一定的算力支持。算力门槛一个轻量级的CNN模型如MobileNet, ShuffleNet变种在推理时也需要数百MFLOPS到数GFLOPS的算力。普通的单片机如STM32H7系列虽然也能通过CMSIS-NN库跑极简模型但处理速度往往需要数秒和模型复杂度受限严重难以满足实时性要求通常要求小于300ms。Jetson Nano的优势它拥有128核的Maxwell架构GPU专为并行计算设计运行优化后的TensorRT引擎推理一个轻量级CNN模型仅需几十毫秒。其自带的CSI摄像头接口和丰富的GPU加速视觉库如OpenCV with CUDA使得图像采集、预处理到推理的流水线可以高度优化延迟极低。生态与开发效率基于Ubuntu系统Python和C开发环境成熟调试工具丰富。在紧张的赛期里能快速验证算法、迭代模型是至关重要的。如果选用其他嵌入式AI芯片如RK3399 地平线旭日等在当时的资料和社区支持上Jetson Nano更占优。所以选择Jetson Nano本质上是选择了“在嵌入式端实现可靠深度学习推理”的最短路径。2.2 运动控制核心STM32F4的精准与可靠那么为什么不用Jetson Nano直接控制电机呢让一个Linux系统直接发PWM波不是不行但存在巨大风险。实时性保障电机控制、编码器反馈、PID运算需要微秒级的精确定时和中断响应。Linux作为一个非实时操作系统其内核调度、内存管理会带来不可预测的延迟从几毫秒到几十毫秒可能导致控制环路不稳定小车出现抖动、甚至失控。系统稳定性图像识别、模型推理是计算密集型任务可能短暂占用大量CPU资源。如果此时电机控制线程被抢占后果不堪设想。STM32F4作为裸机或RTOS运行可以保证控制任务的最高优先级和确定的执行周期。资源与可靠性STM32F4的GPIO、定时器、ADC等外设专为控制设计直接寄存器操作响应快、可靠性高。将运动控制剥离到独立的MCU上实现了功能解耦也降低了整个系统的复杂度。Jetson Nano通过UART或USB与STM32F4通信发送识别结果和高级指令STM32F4负责将这些指令转化为精准的轮子转速和转向角度。这种“AI大脑Jetson Nano 运动小脑STM32F4”的架构完美兼顾了复杂计算的需求和控制任务的实时可靠是当年顶尖队伍的标配思路。2.3 系统通信设计UART的朴素与高效两者之间如何通信我们放弃了I2C、SPI甚至CAN选择了最经典的UART串口。为什么是UART首先通信内容很简单Jetson Nano - STM32F4发送识别到的数字如‘3’或指令码如‘S’表示停止STM32F4 - Jetson Nano发送状态反馈如‘R’表示准备就绪。数据量极小波特率115200甚至9600都绰绰有余。可靠性UART协议简单硬件兼容性极好几乎不会出现驱动问题。在电磁环境复杂的赛场上简单意味着稳定。我们曾测试过SPI在杜邦线稍长时就会出现数据错乱而UART在同样条件下表现稳健。调试便利双方都可以方便地通过串口打印调试信息到电脑极大简化了联调过程。我们设计了一个非常精简的文本协议例如# Jetson 发送识别结果 J-F: NUM,3\n # STM32 反馈动作完成 F-J: ACK,DONE\n协议末尾的\n换行符作为帧结束符便于使用readline()等函数解析避免了复杂的帧头帧尾和校验对于这种低速率、近距离通信出错概率极低必要时可加入简单校验和。3. 数字识别模型从数据集构建到TensorRT部署这是整个项目的灵魂。模型的好坏直接决定了小车的“智商”。3.1 数据集自己造才能应对真实赛场我们最初也尝试过MNIST数据集但效果很差。原因在于场景差异MNIST是标准手写数字背景干净数字居中且规整。而赛题中的数字可能是打印体、贴纸背景是木质或深色比赛场地存在光照不均、透视变形、部分反光等问题。因此自建数据集是必须的。我们的方法如下数据采集使用比赛同款摄像头通常是罗技C270或类似型号在多种光照条件自然光、室内顶光、侧光、暗光下以不同角度、不同距离拍摄贴有数字的赛板或纸张。我们采集了大约2000张原始图像。数据标注使用labelImg工具进行标注。这里的关键是标注框Bounding Box要尽可能紧贴数字边缘减少背景干扰。标注文件保存为PASCAL VOC格式的XML。数据增强这是提升模型泛化能力的关键。我们对原始数据集进行了离线增强包括几何变换随机旋转±15°、缩放0.8-1.2倍、平移±10%。像素变换随机调整亮度±30%、对比度±20%、添加高斯噪声。模拟赛场干扰随机添加小块遮挡模拟污渍、模拟轻微运动模糊。 经过增强数据集扩充到约10000张图像。我们将80%用于训练10%用于验证10%用于测试。3.2 模型选择与训练YOLOv5s的轻量化实战目标检测模型我们选择了YOLOv5s。为什么不是更轻的YOLOv5n或者MobileNet-SSD精度与速度的平衡YOLOv5s在COCO数据集上mAP约56%速度在Jetson Nano上使用TensorRT也能达到30FPS完全满足实时性要求。YOLOv5n虽然更快但精度下降明显在复杂背景下可能漏检或误检我们经测试后发现其稳定性不足以应对赛场的严苛条件。易于部署YOLOv5的PyTorch实现成熟并且官方提供了完善的导出到ONNX再到TensorRT的流程社区资料丰富踩坑容易找到解决方案。我们的训练细节输入尺寸设置为640x640。这是YOLOv5的经典输入尺寸也是TensorRT优化较好的尺寸。预训练权重使用在COCO上预训练的yolov5s.pt权重进行迁移学习可以极大加快收敛速度。关键训练参数epochs: 300 batch_size: 16 # 根据Nano的GPU内存调整可设为8或16 lr0: 0.01 # 初始学习率 weight_decay: 0.0005类别定义由于只识别数字0-9所以nc: 10。注意我们的数据集里“0”就是数字零不是背景。损失函数监控重点关注box_loss和obj_loss的下降曲线。在验证集上我们达到了99.5%的mAP0.5即IOU阈值设为0.5时的平均精度这确保了极高的识别准确率。3.3 TensorRT部署榨干Jetson Nano的每一分算力PyTorch模型直接运行在Jetson Nano上速度不够必须转换为TensorRT引擎。导出ONNX使用YOLOv5自带的export.py脚本将训练好的PyTorch模型.pt文件导出为ONNX格式。这里有一个大坑务必指定动态维度dynamic以适应不同批处理大小用于训练和单张推理。python export.py --weights best.pt --include onnx --dynamic生成TensorRT引擎在Jetson Nano上使用trtexec工具TensorRT自带或编写Python脚本进行转换。我们采用Python脚本以便集成到最终程序中。import tensorrt as trt logger trt.Logger(trt.Logger.WARNING) builder trt.Builder(logger) network builder.create_network(1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser trt.OnnxParser(network, logger) # 解析ONNX模型 with open(“model.onnx”, “rb”) as f: parser.parse(f.read()) # 配置优化参数 config builder.create_builder_config() config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 1 30) # 1GB workspace config.set_flag(trt.BuilderFlag.FP16) # 启用FP16精度大幅提升速度精度损失可接受 # 构建引擎并序列化保存 serialized_engine builder.build_serialized_network(network, config) with open(“model.engine”, “wb”) as f: f.write(serialized_engine)启用FP16是关键一步它能让推理速度提升近一倍而对数字识别这种任务的精度影响微乎其微我们测试中准确率下降小于0.1%。推理脚本编写加载.engine文件进行前向推理。需要处理TensorRT的输出格式不同于PyTorch并进行非极大值抑制NMS后处理。这部分代码需要仔细对照模型结构来编写。4. 软件系统搭建与多线程协同光有模型还不够需要一个健壮的软件系统来调度摄像头、运行推理、处理结果并通信。4.1 图像采集与预处理流水线我们使用OpenCV的GStreamer管道从CSI摄像头采集图像因为它的延迟比cv2.VideoCapture更低。def gstreamer_pipeline(capture_width640, capture_height480): return ( “nvarguscamerasrc ! “ “video/x-raw(memory:NVMM), width(int)%d, height(int)%d, format(string)NV12, framerate(fraction)30/1 ! “ “nvvidconv flip-method0 ! “ “video/x-raw, width(int)%d, height(int)%d, format(string)BGRx ! “ “videoconvert ! “ “video/x-raw, format(string)BGR ! appsink” % (capture_width, capture_height, capture_width, capture_height) ) cap cv2.VideoCapture(gstreamer_pipeline(), cv2.CAP_GSTREAMER)预处理步骤在CPU上完成但尽量优化尺寸缩放将采集的图像缩放到模型输入尺寸640x640。颜色空间转换BGR转RGB如果模型训练时用的是RGB。归一化像素值除以255.0并转换为float32。注意这些操作应使用cv2函数并尽量向量化避免低效的循环。4.2 多线程设计避免I/O阻塞推理这是保证实时性的关键。我们采用生产者-消费者模型使用两个线程和一个队列线程1生产者图像采集线程唯一职责以最高帧率从摄像头读取帧。将帧放入一个固定长度的队列如长度为2的deque。如果队列已满则丢弃最旧的帧。这保证了推理线程总能拿到最新的图像避免了因推理速度慢导致的图像堆积和延迟增大。线程2消费者推理与通信线程从队列中取出一帧。执行预处理和TensorRT推理。解析检测结果获取数字类别和置信度。通过串口将识别结果发送给STM32。重要这个线程的循环频率不一定和采集线程一致它以自己的最大速度运行。使用Python的threading模块和collections.deque可以简单实现。这种设计确保了图像采集不被推理过程阻塞系统整体吞吐量最高。4.3 通信模块与状态机通信线程在获取到有效识别结果后需要决策何时发送。我们实现了一个简单的状态机去抖处理连续识别到同一个数字N次例如3次后才认为该数字是稳定有效的。这避免了因单帧误检导致的误动作。结果过滤只发送置信度高于阈值如0.85的检测结果。对于同时检测到多个数字的情况理论上不应发生但需防御选择置信度最高的一个。协议封装将数字和可能的指令封装成预定义的字符串格式通过串口发送。import serial ser serial.Serial(‘/dev/ttyTHS1’, 115200, timeout1) # Jetson Nano的UART端口 def send_command(cmd): if ser.is_open: message f“CMD,{cmd}\n”.encode(‘utf-8’) ser.write(message) # 可选等待STM32的ACK反馈增加可靠性 # response ser.readline().decode(‘utf-8’).strip() # if response “ACK”: # return True return False5. STM32F4端固件精准控制的实现STM32端是命令的执行者需要稳定可靠。5.1 通信解析与指令处理STM32通过中断方式接收串口数据。// 使用HAL库示例 uint8_t rx_buffer[64]; uint8_t rx_index 0; void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (rx_buffer[rx_index-1] ‘\n’) { // 检测到帧结束符 rx_buffer[rx_index] ‘\0’; // 字符串结束符 process_command((char*)rx_buffer); rx_index 0; } else { HAL_UART_Receive_IT(huart, rx_buffer[rx_index], 1); } }process_command函数解析字符串。例如收到“CMD,3\n”就调用执行number_3_action()函数。5.2 运动控制与任务调度我们使用FreeRTOS来管理多个任务通信解析任务优先级较高负责处理来自Jetson的指令并更新全局指令变量。运动控制任务核心任务以固定频率如100Hz运行。它读取当前指令变量和传感器数据编码器、IMU计算PID输出更新电机PWM。传感器读取任务以较低优先级读取编码器计数、IMU数据等。状态上报任务定时或事件触发下向Jetson Nano发送小车状态如电池电压、错误码。使用RTOS确保了运动控制任务的周期性不受其他任务长时间阻塞的影响这是实现平稳、精准运动的基础。5.3 PID调参与底盘控制小车的移动机构通常是四轮差速或麦克纳姆轮需要精细的PID控制。位置式PID用于定点停车。根据编码器反馈的累计行程控制小车精确移动到目标位置。增量式PID用于速度控制。根据编码器反馈的瞬时速度调整PWM占空比使轮子速度快速稳定在设定值。调参是个经验活。我们的步骤是先P后I再D在速度环上先将I和D设为0逐渐增大P直到系统开始持续振荡然后取该值的60%-70%作为P的初始值。加入积分I逐渐增加I值用于消除静差例如负载不同导致空载和满载速度不一致。I值太大会引起超调振荡。最后加微分DD有助于抑制超调让系统更快稳定。但D对噪声敏感如果编码器数据有抖动需要先对数据进行滤波如滑动平均再加D。我们在调试时会让小车在空载和负载模拟取药后的状态下分别运行确保PID参数在两种状态下都能有较好的性能。6. 系统联调与赛场实战避坑指南这是从“实验室产品”到“赛场武器”的关键一步。6.1 供电与电磁兼容性坑1电源噪声导致Jetson Nano重启或STM32死机。现象小车一跑起来尤其是电机启动或急停时摄像头画面卡住或者STM32程序跑飞。根因电机尤其是有刷电机是巨大的噪声源会产生反向电动势和电流尖峰干扰同一电源网络上的核心控制器。解决方案电源隔离使用独立的电池或电源模块为电机驱动供电如12V为Jetson Nano和STM32核心板供电通过稳压模块降到5V。两者共地但电源输入分开。使用大容量电容在电机驱动板的电源输入端并联多个大容量电解电容如1000uF和瓷片电容0.1uF用于吸收低频和高频噪声。优化布线电机动力线粗线与信号线串口线、编码器线分开走线避免平行靠近。如果必须交叉尽量垂直交叉。6.2 光照与场地适应性坑2场地灯光导致识别失败。现象在实验室白墙背景下识别率99%到了赛场在日光灯或窗户侧光下数字区域过曝或反光模型无法识别。解决方案数据增强时加入过曝模拟在训练数据增强阶段随机对图像局部区域进行高亮处理模拟反光。现场动态调整曝光在比赛现场编写一个简单的曝光调整脚本通过v4l2-ctl命令动态调整摄像头的曝光时间、增益等参数直到在赛板上获得对比度清晰的图像。加入图像预处理在推理前对图像进行直方图均衡化CLAHE或自适应阈值处理增强数字与背景的对比度作为模型输入前的补充。6.3 通信可靠性保障坑3偶发性通信丢包导致动作错误。现象大部分时间正常偶尔小车收到错误数字或没反应。解决方案增加软件重发机制Jetson发送指令后启动一个定时器如果在规定时间内如100ms没有收到STM32的ACK回复则重发指令最多重发3次。指令序列号为每条指令增加一个递增的序列号STM32收到后在ACK中带回该序列号。Jetson可以据此判断是否是最新指令的确认。通信协议容错STM32的解析函数要足够健壮对非预期格式的数据如乱码直接丢弃并回复错误码避免程序崩溃。6.4 代码管理与部署坑4现场调试手忙脚乱版本混乱。解决方案版本控制使用Git管理所有代码Python, C/C赛前打一个稳定的release标签。一键部署脚本编写Shell脚本实现从克隆代码、安装依赖离线包、配置服务到启动程序的自动化。避免在现场输入大量命令。日志系统在Jetson端将关键的识别结果、通信日志、系统状态写入文件。在STM32端可以通过串口调试助手打印日志。出现问题时第一件事是查日志。7. 源码与数据集使用指南我们的项目源码和数据集已经整理开源。这里简要说明核心结构和使用方法。7.1 项目源码结构smart_car_f2021/ ├── README.md ├── jetson_nano/ │ ├── requirements.txt # Python依赖 │ ├── train/ # 模型训练相关 │ │ ├── data/ # 数据集yaml配置 │ │ ├── dataset/ # 图像和标注文件需自行下载 │ │ └── train.py # 训练脚本 │ ├── export/ # 模型导出脚本 │ └── inference/ # 部署与推理主程序 │ ├── trt_model.py # TensorRT引擎加载与推理类 │ ├── camera_thread.py # 多线程采集模块 │ ├── serial_comm.py # 串口通信模块 │ └── main.py # 主程序入口 ├── stm32_f4/ │ ├── Core/ # 标准HAL工程文件 │ ├── Drivers/ │ ├── FreeRTOS/ # RTOS配置文件 │ ├── App/ │ │ ├── tasks.c # FreeRTOS任务定义 │ │ ├── uart_handler.c # 串口指令解析 │ │ └── motor_control.c # 电机PID控制 │ └── README.md # 编译与下载说明 └── docs/ # 硬件连接图、参数说明等7.2 数据集获取与使用数据集由于较大已上传至网盘链接见项目README。解压后按照YOLOv5要求的目录结构放置dataset/ ├── images/ │ ├── train/ # 训练集图片 │ └── val/ # 验证集图片 └── labels/ ├── train/ # 训练集标签YOLO格式txt └── val/ # 验证集标签在train/data/digits.yaml中配置正确的路径即可开始训练。7.3 快速上手步骤硬件连接参照docs/中的接线图连接Jetson Nano、STM32、摄像头、电机驱动和电源。环境配置Jetsoncd jetson_nano pip install -r requirements.txt # 建议使用虚拟环境 # 根据你的摄像头型号可能需要调整main.py中的GStreamer管道模型部署如果你不想重新训练可以直接使用我们提供的预训练TensorRT引擎文件.engine放入inference/目录。如果想从头体验则运行训练和导出脚本。编译STM32固件使用STM32CubeIDE或Keil打开stm32_f4工程根据你的具体板型如F407VE调整引脚定义编译后下载到开发板。联调测试先分别测试Jetson的识别功能和STM32的马达控制功能。然后连接串口运行Jetson上的main.py观察小车是否能根据识别到的数字正确动作。这个项目最宝贵的可能不是那99.5%的识别率而是整个过程中对嵌入式AI系统级问题的思考和解法。从硬件选型开始就要考虑计算、控制、通信的边界到软件开发要处理多线程、实时性、可靠性最后到系统集成还要和电磁环境、物理世界的不确定性做斗争。它更像一个微缩的产品开发流程每一个环节的疏漏都可能被赛场无限放大。希望这份详细的拆解能帮你绕过我们曾经踩过的那些坑更顺畅地搭建起属于自己的智能小车系统。