专注毕业设计软硬件结合方向，技术栈包括
Qt、SpringBoot、Vue、Web、APP、小程序，以及树莓派、ESP32、STM32、Arduino 等平台。可提供：系统功能设计、软硬件架构设计、关键电路参考、核心代码讲解、测试方案设计、项目文档整理、开题/中期/论文/答辩学习辅导。
双轮平衡车是一个「看起来小、调起来难」的方向。车身要靠自己站稳，还要根据画面里的目标主动调整方向，这意味着需要同时解决姿态控制、运动执行和视觉判断三件事。如果正在找一个能做出实物、又有一定技术深度的毕设题目，这个方向值得认真评估。
本文面向还在选题阶段的同学，结合一套 STM32+K210 两轮平衡车方案，讲清楚它适合谁、要解决什么问题、工作量分布在哪里。
一、这个题目适合哪些同学？
这个题目通常推荐给两类同学：
第一类是已经跑通过单片机基础实验的同学。至少做过 GPIO、定时器、串口、PWM 输出中的两三项，知道怎么读传感器数据、怎么驱动电机。如果连点灯和串口打印都还没调顺，直接做平衡车会卡很久。
第二类是想把嵌入式和机器视觉串起来的同学。视觉端用的是 K210 加 MaixPy，不需要自己训练复杂模型，但要理解检测结果的坐标含义，以及怎么把坐标转换成运动指令。
| 选题维度 | 本题目的特点 |
|---|---|
| 适合专业 | 自动化、电子信息、嵌入式、机器人工程 |
| 技术主线 | STM32 负责底盘控制，K210 负责视觉检测，两者通过串口交互 |
| 前置基础 | C 语言、基本电路知识、STM32 定时器与串口，能阅读 Python 脚本 |
| 核心挑战 | 底盘平衡参数调试、视觉目标位置与运动指令的衔接 |
如果只做过纯软件项目，第一次接触电机、姿态传感器和硬件调试，建议先预留出两倍的时间。这个题目的难度不在代码量，而在把多个子系统联调稳定。
二、要解决的问题是什么？
这个题目要回答两个层面的问题。
第一层，怎么让车身保持平衡。双轮平衡车的机械结构本质上是一个倒立摆：重心在轮轴上方，静止时一定会倒。需要让传感器实时感知车身倾斜角度，再用电机给出一个反向力矩，把车身「撑」在目标角度附近。只要控制 loop 足够及时、参数合适，小车就能站稳。
第二层，怎么让小车朝着目标移动。站稳之后，还要根据视觉端传来的目标位置决定前进、后退、左转、右转。这里不能简单理解为「看见人就追上去」，而是要先判断目标在画面中的位置，再生成一串底盘能识别的运动请求，最后由底盘结合自身平衡状态执行。
两个层面组合在一起，系统的数据流大致如下：
上图表示系统模块之间的数据关系，不是具体接线图。
所以选题前要想清楚：兴趣点在「控制算法」还是「视觉应用」？前者会更深入地研究 PID、姿态解算和电机响应；后者会更多地研究模型部署、坐标转换和通信协议。两者都能做，但侧重点不同。
三、核心功能与完成范围
可以把完成范围分成「基础版」和「进阶版」两个档位。第一版先把基础功能跑通，第二版再根据自己的时间和能力加一个改进点。
基础版（必做）
基础版的核心是：小车能站稳，视觉端能根据目标位置发出方向请求，底盘能解析并尝试响应。具体包括：
- 底盘能读取 MPU6050 姿态数据，计算出车身倾斜角度；
- 底盘通过 PWM 驱动左右电机，实现角度环和速度环控制；
- 视觉端通过 K210 运行目标检测，获取目标在画面中的位置；
- 视觉端根据目标位置生成前进/后退/左转/右转请求，通过串口发给底盘；
- 底盘解析串口请求，结合自身平衡状态输出电机控制量。
进阶版（选做）
进阶版不建议一次性加太多功能，而是在基础版的某一处做深入。常见的选择有：
| 改进方向 | 需要额外研究的内容 | 能验证的指标 |
|---|---|---|
| 目标选择策略 | 多人场景下锁定同一个目标，而不是反复切换 | 目标切换次数、丢失后重新锁定时间 |
| 指令平滑 | 检测框抖动导致指令频繁变化，加入死区或滤波 | 单位时间内指令切换次数 |
| 通信可靠性 | 视觉端卡住或串口中断时，底盘能否安全停止跟随 | 中断后是否及时清除跟随请求 |
| 距离估计 | 用检测框大小或额外测距模块估计实际距离 | 不同距离下的响应一致性 |
开题时不要写「实现精准人体跟随」。这种表述把目标定得太死，验收时很难证明。更稳妥的说法是：「实现基于视觉目标位置的平衡车方向响应，并围绕某一改进点完成对比实验」。范围明确了，答辩时也更容易讲清楚做了什么。
四、难度、依赖与工作量
1. 技术难点
难点一：平衡参数和机械结构强相关。同样的控制思路，换一组电机、换一个底盘重心位置、换一块电池，表现都会不同。调试时要记录每一次改动，否则小车表现变好了，也不知道是哪项起了作用。
难点二：画面位置不等于真实距离。视觉端通常根据目标在画面中的坐标判断方向，但目标大小、摄像头俯仰角、人体姿态都会影响结果。如果直接把它当作「距离」来用，容易出现误判。
难点三：多个运动请求可能互相覆盖。视觉端一帧图像可能同时生成前进和转向两个请求，而底盘的状态变量是有限的。需要明确优先级：是先转向还是先前进？多个请求怎么合并？
2. 前置依赖
| 模块 | 需要准备的内容 |
|---|---|
| 机械结构 | 双轮底盘、电机固定、电池仓、上下层支架 |
| 主控 | STM32F1 系列最小系统板，下载接口与供电 |
| 姿态传感器 | MPU6050 模块，I2C 连接与安装方向 |
| 视觉模块 | K210 开发板，摄像头、LCD 屏（可选但方便调试） |
| 电机与驱动 | 带编码器的直流减速电机、H 桥驱动模块 |
| 电源 | 电池、降压模块，分别给电机和逻辑电路供电 |
| 调试工具 | 下载器、串口助手、支架或绑带（防止小车乱跑） |
3. 时间分配建议
不要把全部时间留给写代码。一个合理的分配是：
| 阶段 | 建议占比 | 主要任务 |
|---|---|---|
| 硬件搭建 | 20% | 底盘组装、传感器安装、电机方向确认 |
| 底盘调试 | 30% | 姿态读取、电机驱动、平衡参数初调 |
| 视觉调试 | 20% | 检测模型运行、坐标判断、串口发送 |
| 整机联调 | 20% | 通信协议、运动响应、异常处理 |
| 实验记录 | 10% | 对比测试、现象记录、论文撰写 |
如果前期底盘都站不稳，不要急着接视觉。先把一个子系统做扎实，比同时推进三个子系统更省时间。
五、可扩展方向与开题建议
这个题目的好处是：基础功能边界清晰，改进点也很多。只要围绕一个改进点做实验，就能形成完整的技术内容。以下方向都可以作为毕设的切入点：
- 目标选择策略：从「只跟画面里最大的目标」升级到「锁定首次出现的目标」或「按特征筛选」，减少多人场景下的切换。
- 指令平滑与优先级：给横向、纵向两个方向分别设置死区和优先级，避免一帧图像产生反复切换的指令。
- 通信超时与故障保护：视觉端长时间无更新时，底盘自动清除跟随请求，只保留必要的平衡控制。
- 测距辅助：增加超声波或深度信息，把「画面中的远近」转换成更可靠的距离判断。
开题前，建议确认三件事：
第一，目标是「基本平衡 + 视觉方向响应」，还是进一步实现「指定目标持续跟随」？后者需要更复杂的目标管理。
第二，底盘、摄像头和开发环境是否已经具备？如果还需要自己设计机械结构，工作量要单独评估。
第三，准备验证哪一个改进点？可以从目标选择、指令平滑、通信超时或测距中挑一个，围绕它设计对比实验。
如果也在考虑平衡车或视觉跟随类毕设，可以在评论区说明已经有的主控板、是否具备底盘，以及目前卡在平衡控制还是视觉联调。后续的项目展示和技术讲解文章会围绕这些具体问题继续展开。
