STM32智能行李箱毕业设计全解析：从硬件选型到代码实现

简介：本资源是一套基于STM32F10x系列微控制器的智能行李箱系统完整开发套件，面向高校计算机、电子、自动化等专业本科生开展毕业设计、课程设计及嵌入式实践教学使用。系统涵盖电机驱动、LCD人机交互、超声波避障、蓝牙通信与电源管理等核心功能模块，源码经Keil MDK平台编译验证，配套文档详述硬件连接、软件架构与调试要点。压缩包共286个文件，含40余个C/H源码文件、41个编译中间文件（.o/.d）、47个工程备份（.zbak）及可执行镜像（.hex），辅以bat一键清理脚本、链接脚本（.sct）和项目工程文件（.uvproj），整体大小为8.68MB。已有55人下载学习，提供开箱即用的软硬件协同方案，支持快速部署验证，并预留扩展接口便于后续集成GPS定位或环境温湿度感知等进阶功能。 从选题到落地，STM32智能行李箱项目是我做过的毕设里覆盖知识面最完整的一个——从传感器采集、无线通信、低功耗策略到机械结构配合都有涉及。这篇文章我会把整个项目的设计思路、硬件选型、代码实现和调试过程完整拆开讲一遍，重点放在“为什么这么选”和“实际做的时候哪里会踩坑”，不管是拿来当毕业设计参考还是自己想动手做一个，都能少走不少弯路。

1. 项目整体设计与方案选型拆解

1.1 功能需求怎么定：先做减法再做加法

智能行李箱在市面上已经不算新物种了，但作为毕业设计或者个人练手项目，它的优势在于功能边界清晰、技术栈覆盖广、呈现效果好。我见过不少人一上来就把方案定成“全功能旗舰版”——要跟随、要指纹识别、要人脸解锁、还要太阳能充电，最后做了一年还没稳定跑通。这个项目最忌讳的就是功能失控。

我最终锁定了四个核心功能外加一个辅助显示：

• 电子称重：解决托运超重问题，通过压力传感器实时测量箱体重量
• 蓝牙解锁：手机APP控制电磁锁开锁/上锁，替代传统密码锁
• GPS定位与GPRS远程查询：箱体丢失或遗忘时，通过手机远程获取位置信息
• 防丢提醒：蓝牙连接断开时蜂鸣器报警
• OLED状态屏：显示当前重量、GPS状态、电量、锁状态

这套功能组合的好处很明显：每个功能都有独立的传感器和通信链路，它们之间没有复杂的耦合关系，可以分模块逐个调试。同时，称重、定位、无线通信这几个方向正好覆盖了嵌入式开发的常见知识点，答辩时每个模块都能展开讲。更重要的是，全部功能用STM32F103C8T6这颗芯片就能跑下来，物料成本控制在200块以内，对个人项目来说完全可接受。

1.2 主控选型：为什么是STM32F103C8T6而不是51或ESP32

这里需要重点说一下主控选型，因为很多新手会在这一步纠结很久。市面上做智能行李箱的主控方案无非就是51、STM32、ESP32这三类，各自的优劣势非常明显。

51单片机的问题在于资源太紧张。智能行李箱需要同时处理HX711的数据转换、GPS的串口数据流、蓝牙的通信指令、OLED的刷新，这套活下来51的8位处理能力和几KB的RAM根本不够用。你可能能做出来，但代码会写得极为痛苦，各种外部中断和定时器打架。而ESP32虽然性能强、自带WiFi和蓝牙，但这个项目用它的蓝牙和WiFi都属于“高配低用”，而且ESP32的启动电流和运行功耗比STM32高不少，对电池供电方案不友好。再加上很多学校的课程体系和毕业设计指导老师对STM32更熟悉，用ESP32出了基础问题求助都不太方便。

STM32F103C8T6是权衡下来最合适的方案：72MHz主频处理GPS数据流绰绰有余，20KB RAM足够跑各种缓冲区，64KB Flash放标准库工程也够用（实际上这颗芯片是128KB Flash，市面上标的64KB是官方保守值）。更重要的是，ST-Link下载器便宜、调试工具成熟、参考例程铺天盖地，遇到问题随便一搜就有答案。对于毕设这种“时间紧、必须出成果”的场景，选一个资料最多、社区最活跃的平台本身就是最优解。

1.3 系统架构和供电方案：所有模块共用一颗电池的代价

整个系统的硬件架构可以分成三个层次：传感器层（压力传感器、GPS模块）、通信层（蓝牙模块、GPRS模块）、执行与交互层（电磁锁、蜂鸣器、OLED），由STM32主控统一调度。

供电方案是很多人会忽略的硬骨头。我实测过，整个系统最大的坑就在电源上。GPS模块工作时峰值电流能到200mA，电磁锁动作瞬间电流高达2A，如果这几个模块同时工作，电压跌落会直接导致单片机复位。

我的做法是：电池端用一个锂电池保护板加一个1000uF电解电容稳住大电流冲击，主控部分用LM1117-3.3稳压，传感器和通信模块单独用MOS管控制供电。这样做的好处是每个模块都可以独立断电，既解决了电源干扰问题，也为后面的低功耗设计留了后路。这里有一个很关键的细节：电磁锁一定要独立供电，不能和主控共用同一路LDO，否则锁一吸合单片机必死机。

2. 核心功能模块解析与硬件实现

2.1 电子称重模块：HX711从接线到校准的完整细节

称重功能是整个项目里最容易“看起来简单、做起来翻车”的模块。我用的方案是电阻应变式压力传感器加HX711专用ADC。压力传感器的原理不复杂：金属箔应变片贴在弹性体上，受力后应变片阻值变化，通过惠斯通电桥把阻值变化转换成毫伏级的电压信号。问题在于这个信号太微弱了，如果直接接STM32的ADC，分辨率根本不够——满量程100kg时输出信号也才20mV左右，STM32的12位ADC在3.3V参考电压下每个LSB对应0.8mV，换算下来只能分辨4kg的变化，这显然没法用。

HX711就是来解决这个问题的。它是24位ADC，内部带有128倍可编程增益放大器，能把毫伏级的信号放大到合适的范围。接线非常简单：VCC接3.3V、GND接地、DOUT接一个GPIO输入、SCK接一个GPIO输出。通信方式是典型的时序模拟——主机通过SCK的高电平脉冲来控制DOUT输出数据，读取24位二进制补码。HX711的工作电压范围是2.6V到5.5V，所以3.3V供电没问题。

接线容易，真正的难点在机械结构。压力传感器必须固定在一个能均匀受力的底座上，我一开始直接用螺丝把传感器锁在行李箱底板，结果发现重量稍微偏一点读数就东倒西歪。后来在传感器和底板之间加了一层2mm厚的橡胶垫，四个角的固定螺丝也不能拧死，要留一点活动余量，让传感器能感受到真实的压力变形。这里有一个经验：安装好后用额定重量的物体压一下，如果数据回零时反复跳动，多半是传感器变形没复位或者螺丝过紧。

校准这块也有讲究。HX711读出来的是AD值，要换算成重量必须做两点标定。简单说就是：空载时读取一个AD值作为零点，放一个已知重量的标准砝码再读取一个AD值，用差值算出比例系数。我在代码里用了一个结构体保存零点值和比例系数，每次上电后先自动去皮再进入称重状态。实际称重的误差可以控制在±0.1kg以内，基本满足日常使用需求。

2.2 定位与通信模块：GPS搜星和GPRS上传的AT指令实战

GPS定位这块用的是SIM808模块，它集成了GPS和GPRS功能，一颗模块搞定定位和数据上传，对PCB面积和系统复杂度都友好。不过SIM808现在不太好买到了，第二代可以用SIM7600CE或者单独买GPS模块加4G模块来替代，AT指令的思想是通用的。

GPS模块上电后需要一段时间搜星，冷启动通常要30秒到3分钟，这正是很多新手以为模块坏了的地方。判断GPS是否正常工作有一个标准：看串口输出的NMEA语句。GPS模块默认通过串口输出4800或9600波特率的数据，其中$GPRMC语句里的状态位是A表示定位成功，是V表示还在搜星。我在代码里做了个状态机专门处理这个问题——上电后先等GPS状态位变成A，超过2分钟还没定位就通过蜂鸣器提示用户。

GPRS数据上传走的是AT指令，流程上有固定的套路：先AT+CREG?查询是否注册上网络，然后AT+CGATT=1附着GPRS网络，再AT+CIPSTART="TCP","服务器地址",8080建立TCP连接，最后AT+CIPSEND发送数据。整个过程看起来繁琐，但每一步都有明确的返回状态码，哪个环节出错都能定位到具体指令。

这里有个实操细节值得留意：SIM800系列的模块上电后至少要等2秒才能接收AT指令，如果上电后立刻发指令就会收到一堆乱码或者没有任何响应。我的代码里在GPRS模块上电后硬性延迟2秒，再发一条AT测试看返回OK才继续后续流程。这个细节让我少排查了一整晚的不明问题。

2.3 解锁与防丢：蓝牙模块和电磁锁的驱动电路

蓝牙模块用了HC-05，原因是它既支持蓝牙2.0经典蓝牙，又能通过AT指令配置主从模式。手机APP通过蓝牙发送开锁指令，STM32解析后控制电磁锁动作。

HC-05的使用有几个关键参数需要配置：密码默认是1234，波特率默认是9600（部分版本是38400），模块名字可以改成自己想要的。配置AT指令时需要注意一个常见的坑：HC-05进入AT模式需要按住模块上的按钮再上电，不是随时都能发AT指令的。另一个坑是HC-05的VCC接5V时逻辑电平是5V，直接接STM32的GPIO引脚理论上没问题（STM32的引脚耐压是5V），但稳妥起见中间串一个1K电阻做电平隔离比较好。

电磁锁的驱动是另一个容易出事的地方。行李箱电磁锁的工作电压是12V、电流2A级别，直接拿GPIO控制绝对不行——STM32的GPIO最大输出电流只有25mA。我用了AO3400这个NMOS管来做开关：GPIO输出高电平时NMOS导通，电磁锁通电开锁。电路上加了一个1N5819肖特基二极管反向并联在电磁锁两端，用于吸收断电瞬间的反向电动势，防止电压尖峰打坏MOS管或单片机。

防丢功能用的是蓝牙RSSI信号强度来判断距离。思路是定期读取蓝牙模块的信号强度，低于某个阈值就认为手机离开行李箱超过安全距离。这个方案说实话只能做大概判断，因为RSSI受环境影响很大，墙壁、人体、金属都会让信号急速衰减。我在代码里做了滑动平均来平滑波动，并且设置了连续5次低于阈值才触发报警，避免路过一个障碍物就响一声的尴尬。

2.4 显示与交互：OLED状态屏和按键设计

显示用的0.96寸OLED，SSD1306驱动芯片，I2C接口，四根线（VCC、GND、SCL、SDA）非常简洁。OLED本身不复杂，核心是SSD1306的控制命令和数据缓冲区的关系。我用了常见的4页128*8字节显存结构，先在缓冲区里画好内容再一次性刷到屏幕。

界面设计上我分了三屏：

• 默认屏：实时重量、蓝牙连接状态
• 按一下按键切到第二屏：GPS定位状态、经纬度坐标
• 再按一下切到第三屏：电量信息、系统版本号

这个交互逻辑很简单，但对提升项目的完整度帮助很大。评委看到的不再是一个只会嗡嗡响的箱子，而是有完整交互逻辑的产品原型。

按键部分用了两个物理按键加一个长按/短按区分——短按切换屏幕，长按触发配网或者恢复出厂设置。按键输入一定要做消抖处理，我在代码里用10ms定时器扫描的方式做的软件消抖，效果很稳定，比简单的delay消抖可靠得多。

3. 软件架构与关键代码实现

3.1 工程搭建：从标准库到模块化文件组织

软件部分我选择了标准外设库（Standard Peripheral Library）而不是HAL库。原因有两个：一是标准库的代码直接操作寄存器，逻辑链路短，答辩时讲起来更清晰；二是这个项目的通信逻辑比较复杂，标准库的中断处理和定时器配置写起来反而比HAL库少一层封装。当然，如果学校教学用的是HAL库，那还是跟着学校的节奏走，后面讲的代码逻辑都是一样的。

工程目录沿用了正点原子的经典结构：

Project/ ├── USER/ // main.c、stm32f10x_it.c、系统配置 ├── HARDWARE/ // hx711.c、gps.c、bt.c、oled.c、motor.c ├── SYSTEM/ // delay.c、sys.c、usart.c ├── CORE/ // 启动文件和内核寄存器定义 └── OBJ/ // 编译输出

模块化的核心原则是“每个模块只做一件事，模块之间通过接口通信”。比如HX711模块只负责读取AD值和换算重量，提供给外部的接口函数只有HX711_Init、HX711_Get_Weight、HX711_Tare这三个。GPS模块只负责解析串口数据，对外提供GPS_Get_Info函数。上层主逻辑完全不需要关心底层数据是怎么来的，调试的时候各模块也可以单独验证。

3.2 称重数据的稳定滤波：限幅加均值，双保险

HX711读取的数据原始状态下会有不少噪声，主要来源是机械振动和电源波动。我最终的滤波策略是“限幅滤波+滑动均值滤波”双重处理：先做限幅，相邻两次采样值差超过一定阈值就丢弃这次数据；再做10次滑动平均，平滑输出。

限幅滤波的阈值设定要靠实际测。我用手快速敲击箱体时，AD值跳变的幅度大概是正常静态波动的5倍，所以阈值取静态波动最大值的3倍就比较合适。太大会让真实突变信号漏过去，太小会把正常的速度变化也过滤掉，这个需要实测微调。

滑动均值这里有一个容易忽略的点：如果只用简单的取平均，那么重物放上去的瞬间，输出值会有一个明显的爬坡过程，看起来像是重量在慢慢变大。更好的做法是“加权滑动平均”，最近的采样值权重更高。我用的是4个历史值加当前值的比例分配，实际效果是响应速度快了不少，误差也没变大。

3.3 GPS数据解析：从$GPRMC字符串到经纬度坐标

GPS模块输出的NMEA数据是一堆以$开头的ASCII字符串，其中$GPRMC语句包含的是最常用的定位信息。它的格式大概是：

$GPRMC,083559.00,A,3144.43687,N,12130.07332,E,1.11,0.00,070116,,,A*56

字段用逗号分隔，我这里只需要关注第2个字段（UTC时间）、第3个字段（定位状态，A为有效）、第4个和第6个字段（纬度和经度，格式是度分格式）。需要注意的是，NMEA输出的经纬度是“度分”格式，比如3144.43687表示31度44.43687分，要转换成十进制度数需要除以100取整作为度，余数除以60加上去。

我在串口中断里用环形缓冲区接收GPS数据，主循环里通过找特征字符的方式提取$GPRMC段。这里有一个性能考虑：GPS数据是持续不断输出的，每秒都会刷新好几条语句，如果直接在中断里做字符串解析会拖慢系统响应。我的做法是中断只负责往缓冲区写数据，主循环里空闲时再去解析，这样即使解析慢一点也不会丢数据。

char* p = strstr(recv_buf, "$GPRMC"); if(p) { char status; char lat_str[12], lon_str[12]; sscanf(p, "$GPRMC,%d,%c,%11[^,],%c,%11[^,],%c", &time, &status, lat_str, &lat_dir, lon_str, &lon_dir); if(status == 'A') { // 度分转十进制 gps_info.lat = (atof(lat_str)/100.0) + (fmod(atof(lat_str),100.0)/60.0); // 南纬为负，西经为负，注意处理方向 } }

3.4 主状态机设计：把混乱的逻辑理顺

整个系统的核心逻辑我用了一个简单的状态机来管理。状态机是嵌入式开发里最常用的设计模式，它最大的好处是把“什么条件下做什么事”的关系理得清清楚楚，不会出现if嵌套到怀疑人生的情况。

这个项目的状态机分五个状态：

• INIT：上电初始化，等待所有模块就绪
• IDLE：待机状态，显示基本信息，等待用户操作
• WEIGH：称重状态，持续采集重量数据
• LOCATE：定位状态，等待GPS定位成功并上报位置
• LOCK/UNLOCK：解锁/上锁状态，执行电磁锁动作

状态迁移的条件写在主循环里，每个状态执行完自己的逻辑后跳到下一个状态。比如蓝牙收到开锁指令后，状态从IDLE跳到UNLOCK，电磁锁执行开锁动作，1秒后自动回到IDLE。这比传统的RTOS调度简单得多，但对于这种事件驱动为主的系统完全够用。

3.5 手机端和上位机的通信协议

通信协议是整个系统能否顺畅工作的纽带。我定义了一套简单且健壮的帧格式：

帧头(0xAA 0x55) + 类型(1字节) + 数据长度(1字节) + 数据(0-8字节) + 校验(1字节)

校验用的异或和。这个协议很简单，但很实用：帧头用来做字节同步，长度字段防止粘包，校验字段能识别大部分传输错误。蓝牙指令全部走这套协议，比如开锁指令是AA 55 01 00 00，关锁是AA 55 01 00 01，查询重量是AA 55 02 00 00。

手机端我用的是现成的蓝牙调试助手，没有单独开发APP。如果你需要完整的系统展示，可以用MIT App Inventor做一个简单的蓝牙控制界面，逻辑不难。关键是协议要提前定好，APP端和STM32端的解析代码才能完全对应上。实际测试中发现，蓝牙传输偶尔会出现数据错位的问题，加了异或校验后基本都能识别出来，识别失败直接丢弃等待下一帧。

4. 实测过程与调参记录

4.1 整机联调流程：先分后合，逐模块点亮

整套系统的调试流程我强烈建议“先分后合”，千万别一上来就全部模块接好一起上电。我的顺序是：

• 最小系统板先跑起来，点亮LED，确认主控和下载器正常
• 接OLED，显示字符，验证I2C通信
• 接HX711和压力传感器，做校准和称重测试
• 接GPS模块，在窗边验证定位（室内基本搜不到星）
• 接蓝牙模块，用手机发送指令控制LED翻转，验证通信链路
• 最后再接电磁锁，用MOS管驱动

每接一个模块就单独测试一个模块，这样出了任何问题都能定位到是软件配置还是硬件连接的问题。我最开始的失误是把GPS和蓝牙的串口搞反了——两个都用串口1，结果互抢资源，数据全乱了。后来GPS用串口1、蓝牙用串口2，各走各的通道，立刻稳定下来。

4.2 功耗实测与低功耗优化：一个功能一个开关

电池续航是行李箱能否“真正能用”的关键指标。我实测了各模块的功耗数据：

如果把所有模块都开着，整机电流轻松超过400mA，2000mAh的电池只能撑5个小时，这完全是不可用的状态。我的优化思路很明确：GPS和GPRS是最大头的功耗，但它们不是时时都需要工作的。我在硬件上加了一个由STM32控制的MOS管来独立控制GPS/GPRS模块的电源，平时完全断电，需要定位时才打开。这个改动直接把待机电流从400mA降到了30mA以下，效果立竿见影。

主控本身也做了低功耗处理：空闲时进STOP模式，外部事件唤醒。这个对STM32F103来说不复杂，只需要正确配置时钟和唤醒源。实际测下来整机待机电流能做到2mA左右，配合2000mAh的电池，理论待机可以达到40天。

4.3 机械结构安装：传感器固定和走线的血泪教训

硬件和代码都跑通之后，真正把系统装进真实行李箱才是噩梦的开始。压力传感器的安装位置是最讲究的：它必须放在行李箱底部受力的主路径上，但又不能是整个箱体的唯一承力点——那样传感器会承受过大的剪切力而损坏。

我的最终方案是四角各放一个传感器，用全桥接法串联到一个HX711，这样无论重量怎么分布都能准确测量。走线方面，所有传感器线都用了屏蔽线，外层屏蔽层单端接地，不然电机或电磁锁动作时容易耦合进噪声干扰称重数据。给传感器线留了足够的活动空间，防止开关箱时线被夹断。

还有一个机械细节值得留意：电池和电路板的固定位置要避开传感器探头，不然电池的重量会叠加到传感器上导致称重不准。我把电路板装在箱体侧面上部，电池和传感器分离布置，实测称重误差控制在0.1kg以内。

5. 常见问题与排查技巧实录

5.1 GPS一直搜不到星，卡在定位状态

这个问题我调了一整个下午才找到原因，后来发现其实是两个问题叠加。第一个是天线位置：行李箱内部金属框架对GPS信号屏蔽严重，我把天线贴在箱体里面，搜星数量永远不超过3颗。解决办法很简单，用带磁吸底座的GPS有源天线，贴到行李箱外壳表面，搜星数量立刻到了10颗以上。

第二个问题是波特率匹配。SIM808模块默认GPS输出波特率是9600，但有些厂家的模块出厂设置为38400或者115200，用错波特率时解析出来的全是乱码。排查方法很直接：用USB转TTL直接接模块，看电脑串口助手里是否有正常格式的NMEA输出，没有就试不同的波特率。一旦确认波特率，就在代码里配置对应的串口参数。

5.2 称重数据跳变，一碰箱子数值就乱跳

这个问题排查起来相对容易，主要怀疑对象是电源干扰和机械振动。电磁锁吸合、GPRS发送数据的瞬间，摄像头抓到的AD值会突然跳一大截。后来我在HX711的供电端并了一个10uF和一个100nF的电容，并在传感器信号线和地线之间加了一个100nF电容，高频噪声明显减少。软件方面，我在读取AD值时加了延时——SCK的时钟周期不能太短，HX711要求最小400ns高电平时间，我用的延时函数实际能到1us级别，两个都满足。最终滤波处理加限幅也帮了大忙。

5.3 蓝牙连上就断开，传输数据乱码

蓝牙连接不稳定，优先查这两点：供电和波特率。HC-05非常敏感，供电电压纹波大的时候就会出现连接时断时续的情况，我给它加了独立的3.3V LDO供电，问题直接消失。波特率不匹配则会造成双方握手成功后第一包数据就开始乱码——手机端设置为9600，STM32的USART也设置为9600，两边必须一致。

另一个隐蔽的坑是HC-05的数据位格式。默认是8N1（8数据位无校验1停止位），但如果模块被配置成其他格式，即使波特率一样照样乱码。可以通过AT+UART指令查询当前配置。

5.4 ST-Link下载失败，芯片无法识别

这个问题在所有STM32项目里都出现过。ST-Link提示找不到器件，通常的排查顺序是：

• 确认ST-Link与目标板的接线：SWDIO接PA13、SWCLK接PA14、GND共地、3.3V供电
• 确认目标板供电正常，核心板上有电源指示灯亮
• 如果之前烧录过禁用SWD引脚的代码，需要把BOOT0拉高，用串口ISP方式擦除Flash
• 最后检查ST-Link的固件版本，用STM32 ST-LINK Utility升级一下

BOOT0拉高是个救命技巧。如果代码里不小心把PA13和PA14配置成了普通GPIO，SWD下载就完全失灵了。把BOOT0接到3.3V后上电，芯片会从系统存储器启动，这样就能通过串口擦除Flash恢复。

5.5 排查技巧速查表

6. 源码与文档组织：毕设资料的整理思路

6.1 源码的版本管理和注释规范

写毕业设计和写公司项目最大的区别在于：你的代码是要被评委老师看的，而不是只跑起来就行。我在项目一开始就用了Git管理代码，每个模块开发完打一个tag，答辩前把整个仓库导出成zip。这样无论怎么改代码，都有历史可以回溯，出了问题也能对比版本找原因。

代码注释也很关键，但不是那种每行都写注释的做法，而是“关键逻辑写清楚，普通代码留空白”。答辩时老师最常问的问题是“这段代码是干什么的”“为什么这么写”，如果自己在注释里写清楚了，回答起来就不会卡壳。我对于HX711的时序、GPS的解析逻辑、状态机的迁移条件都写了详细注释，后来写论文时这些注释直接变成了章节的素材。

6.2 开发文档和论文的组织架构

整套项目的文档我分成了四份：

• 需求分析文档：明确功能列表、性能指标（称重精度、定位精度、功耗指标）
• 硬件设计文档：原理图、PCB布局说明、BOM清单、电源树设计
• 软件设计文档：模块划分、接口定义、状态机图、通信协议说明
• 测试报告：各模块测试数据、整机测试结果、问题记录和解决方案

这份文档的价值在论文阶段体现得尤其明显。写论文的时候，软件设计文档里的接口定义和状态机图直接变成论文第四章的内容模板，测试报告则一个字一个字地改成了论文第五章的验证部分。我见过很多同学最后熬几个通宵憋论文，就是因为平时没有积累过程文档。

6.3 答辩环节的准备：从演示到提问

毕设答辩的常规流程是先讲PPT再演示实物，最后是老师提问。演示环节最重要的是“预案”——万一现场GPS搜不到星怎么办？万一蓝牙连不上怎么办？我的处理方式是准备了两套演示路径：优先演示摄像头最想看的核心功能，比如称重和蓝牙解锁；如果GPS现场搜星很慢，就提前录好一段定位成功的视频作为备用。别把现场演示的赌注押在运气上。

老师提问环节的高频问题基本集中在几个方向：

• 为什么选STM32而不选其他方案
• HX711的精度和量程怎么确定的
• RSSI防丢有哪些误差来源
• 低功耗是怎么实现的
• 系统如果做产品化，还需要哪些改进

针对这些问题，我在答辩前自己先写了一遍答案，不超过一句话，但每个都点到了核心。比如低功耗问题的答案是“GPS/GPRS模块通过MOS管独立供电，空闲时关断，主控进STOP模式”，一句话就讲完了，不用啰嗦。

6.4 这个项目还能怎么扩展

如果时间充裕，这个系统有几个很自然的扩展方向：

• 蓝牙升级为BLE蓝牙5.0模块（如CC2541或nRF52832），待机功耗低一个数量级
• 加入UWB定位模块，实现厘米级定位和真正的“跟随行李箱”功能
• 添加4G Cat.1模块替代2G GPRS，解决运营商退网的问题
• 称重数据通过MQTT上传到云平台，在手机端绘制重量变化曲线
• 加入指纹解锁作为箱体侧面的独立解锁方式

这些扩展方向在技术上都有成熟方案，核心的框架不需要大改，只是在现有模块上做加法。

我个人在实际操作中的一个深刻体会是：这个项目单个模块的技术难度其实都不高，真正的难点在于把这么多模块稳定地整合在一起，并且用一个合理的软件架构去管理它们。做完之后回头看，收获最大的反而不是那些具体的技术点，而是理解了“做系统”和“做模块”完全是两回事。如果你也在做类似的项目，建议把重心放在模块间接口的设计和系统级的调试优化上，这部分能力在嵌入式开发里比任何单独的外设驱动都更值钱。希望这份文章能帮你顺利把箱子点亮，少走我之前踩过的那些弯路。

本文还有配套的精品资源，点击获取