尧图网站建设 
简介本资源是一套完整的基于STM32的老人摔倒报警系统毕业设计项目面向电子信息、自动化、嵌入式相关专业本科生解决居家养老场景中老年人突发摔倒后及时报警与救助的核心需求适用于毕业设计、课程设计及期末大作业等实践环节。压缩包共338个文件涵盖76个C源码、68个头文件.h、48个编译中间文件.o/.d/.crf及Keil工程配置.uvprojx/.uvoptx、PCB原理图.schdoc、硬件设计文档.pdf、可执行固件.hex等全面支撑从代码开发、硬件调试到论文撰写的全流程包体大小为14.91MB。已有162人学习下载项目经助教审定、本地实测编译通过评审得分98分难度适中且结构清晰——含传感器数据采集、姿态判断算法、SIM900A短信报警模块驱动及低功耗管理等关键实现配套论文与完整资料可直接用于答辩与复现。 先说说这个项目的来龙去脉。老人摔倒报警装置在毕业设计里属于经典永流传的题目网上方案五花八门但真正能跑通、能复现、答辩能讲清楚的其实不多。我手头做过的这套基于STM32F103C8T6搭配MPU6050六轴传感器配合GPS定位GSM短信报警另加OLED显示和本地蜂鸣器硬件成本控制在百元上下功能覆盖了检测、定位、报警、确认四条完整链路。全文会从硬件选型逻辑、传感器数据采集、跌倒检测算法落地、报警联动机制到联调踩坑一条线讲完适合正在做毕设、或者想给家里老人做一套低成本守护方案的工程师参考。需要说明的是本文基于我实际调试中常用的标准库工程展开HAL库的写法差异我会在关键处标出方便你对着自己的工程改。1. 判断摔倒了这件事传感器到底在测什么1.1 为什么选择MPU6050六轴传感器而不是只用三轴加速度计很多同学一开始想省成本觉得用一个三轴加速度计ADXL345就够判断摔倒了。单看加速度幅值确实能捕捉到摔倒瞬间的冲击但问题在于老人摔倒后如果意识清醒会自己爬起来加速度波形和坐下、躺下、弯腰捡东西非常相似如果意识丧失倒地不动加速度输出又和正常睡觉差不多。只靠加速度一个维度误报和漏报都压不住。MPU6050内部集成了三轴加速度计和三轴陀螺仪可以同时输出加速度和角速度。摔倒过程有一个非常明显的特征姿态发生快速且大幅度的变化。加速度计捕捉冲击合加速度瞬间冲到2g甚至3g以上陀螺仪捕捉旋转角速度在短时间内超过某个阈值两者同时满足再去判断后续是否静止这套逻辑才是工程上可用的。我用的MPU6050模块是常见的GY-521小板板载稳压和I2C上拉电阻3.3V供电直接插杜邦线就能用。虽然模块本身有10位ADC精度但对于跌倒检测这种量级的事件完全够用。如果你想要更精确的姿态角输出可以用BMI160这种带硬件DMP的传感器但代码复杂度和成本都会上来毕设阶段没必要。1.2 跌倒检测的两大算法流派阈值法 vs 状态机阈值法最简单直观不断计算加速度矢量和 [\sqrt{x^2y^2z^2}]设定一个高阈值比如2.5g加速度超过阈值就认为发生了跌倒冲击。这个方法的优点是计算量小、STM32在每次采样间隔内轻松搞定缺点是无法区分老人摔倒和老人把手里东西重重摔在桌上这类冲击。所以实际项目里我做了改进冲击检测只是第一级冲击发生后紧接着检查角速度积分量也就是姿态角变化如果姿态角的改变超过45度且接下来3到5秒内加速度基本没有大幅波动判定为静止或缓慢活动才真正触发报警。这就是一个简单的状态机状态1正常活动合加速度和角速度都在阈值内状态2疑似摔倒合加速度超过冲击阈值状态3确认摔倒冲击后姿态角变化大且进入静止状态4报警触发蜂鸣器和短信通知为什么用状态机而不是直接阈值报警因为老人日常生活中弯腰、侧身、咳嗽都可能产生短暂的冲击状态机通过冲击后是否伴随大幅姿态变化这个条件把绝大多数伪摔倒排除掉了。我在实测中弯腰捡东西这个动作就不会触发报警因为虽然躯干前倾但角速度变化平缓姿态变化达不到摔的剧烈程度。1.3 采样率、滤波和安装位置三个容易被忽略的细节采样率方面MPU6050的加速度计输出速率最高可以到1kHz但我实际配置成50Hz20ms一次采样。跌倒冲击的持续时间大约在300到500ms50Hz采样率下能采到15到25个有效点足够捕获冲击峰值。更高的采样率会占用I2C总线时间和MCU计算资源反而没必要。陀螺仪的量程我设置成±2000dps加速度计量程设置成±16g因为跌倒瞬间角速度和加速度都可能远超日常活动范围量程设小了数据会削顶。滤波方面我用了最简单的滑动平均滤波取最近5次加速度数据的均值参与计算。这个滤波能平滑掉传感器噪声但不会模糊冲击峰值因为滑动窗口足够短。卡尔曼滤波虽然精度高但在STM32F103这种主频72MHz的芯片上算姿态角每个周期要多花好几毫秒对50Hz的采样来看还扛得住但对中断实时性要求高的场景不建议。安装位置我踩过一次坑。最初把模块随便贴在装置外壳中间后来发现不同佩戴位置的加速度波形差异明显绑在腰间和挂在胸前跌倒冲击的方向不一样合加速度的峰值也不同。实测下来绑在胸前或者腰间最稳定因为人体躯干在摔倒时是整体运动传感器能最直接地反映身体姿态变化。装在裤兜里则容易因为腿部动作幅度大产生大量误判建议不要在毕设文档里写这个位置。2. 硬件选型与系统框架一条完整的报警链路是怎么串起来的2.1 主控为什么选STM32F103C8T6而不是51或者ESP3251单片机做这个项目有个致命短板MPU6050的I2C通信虽然简单但51没有硬件I2C靠IO口模拟时序配合浮点运算计算合加速度和姿态角主频12MHz跑起来非常吃力。ESP32虽然性能强、自带WiFi和蓝牙但在毕设场景里裸跑裸调的难度比STM32大资料相对分散而且很多学校的嵌入式课程主线就是STM32答辩时老师对STM32的提问你更容易接住。STM32F103C8T6是Cortex-M3内核72MHz主频20KB RAM64KB Flash带硬件I2C、USART、SPI、ADC等外设。做这个项目RAM和Flash占用大约分别是5KB和30KB左右余量充足。最难得的是它的生态标准外设库、HAL库、LL库加上网上海量的例程任何一个模块的驱动都能找到参考。注意如果后续要加FreeRTOS或者跑LVGL这种人机交互界面建议换STM32F103RCT648KB RAM256KB Flash不然Flash会很紧张。我在这套方案里没有上OS裸机轮询定时器中断就够用了。2.2 定位与通信GPSGSM组合为什么比WiFi方案更贴合场景老人摔倒报警最怕的是什么摔倒后老人无法主动求助需要系统自动通知家属。这个场景对通信链路有两个要求一是覆盖范围广二是能主动触达。WiFi方案依赖家庭路由器老人在楼道、小区花园摔倒时根本没有网络覆盖BLE方案需要家属在附近也不现实。所以GSM/GPRS模块如SIM800C、SIM900A配合GPS模块如ATGM336H或NEO-6M才是真正贴合移动场景的组合。这套组合的工作逻辑是检测到摔倒后STM32先读GPS模块的经纬度、时间数据通过串口发送NMEA协议指令解析然后把预设的告警短信通过GSM模块发送到家属手机号短信内容带上坐标链接比如Google Maps链接。必要时还可以让GSM模块直接拨打家属电话——这个功能在老人失去意识无法接听时尤其重要家属看到来电号码就知道出事了。也有同学问用4G Cat.1模块比如Air724UG行不行当然行Cat.1模块内置了MQTT协议栈可以直接往云平台推数据方案更现代化但价格比GSM模块贵一倍且SIM卡需要开通物联网套餐毕设演示时要考虑学校环境有没有4G信号。我建议基础方案用GSM并在论文里提一句可平滑升级到Cat.1模块这是加分项而不是必选项。2.3 电源方案为什么不能用USB供电直接完事很多同学做完硬件往电脑USB口一插能跑就交差了。但老人摔倒报警装置是便携设备供电方案必须考虑。我分了三路电源主控和传感器用3.3V由AMS1117从5V降压得到GSM模块用4V左右供电SIM800C的VBAT范围是3.4到4.4V峰值电流可达2A必须单独供电GPS模块用3.3V市电供电不现实锂电池是主流。5000mAh的18650电池组两节并联配合充放电管理模块比如TP4056理论续航在GSM模块待机正常检测的场景下能撑一天甚至更久。但GSM模块在发短信时瞬间电流可以冲到1.5A以上如果电池内阻大或者走线细电压会被拉低直接导致模块重启。这个问题我后面专门用一个小节讲属于必须公开的坑。2.4 显示和交互OLED、按键、蜂鸣器的分工OLED我用的是0.96寸I2C接口的SSD1306用来显示当前姿态角、合加速度、系统状态和GPS定位信息这个界面主要是给调试用以及现场演示时让评委直观看到系统在实时检测。按键的作用是人工取消报警一旦系统进入报警状态会先蜂鸣器响同时OLED提示是否取消报警老人如果意识清醒在5秒内按下按键就能取消远程短信这是一个关键的防误报设计。蜂鸣器用的有源蜂鸣器三极管驱动STM32的IO口直接推不动。3. STM32工程搭建与传感器数据采集实战3.1 工程用标准库还是HAL库我的建议这两年HAL库CubeMX成了主流因为CubeMX图形化配置时钟、外设确实快生成的代码结构也规整。但说实话做这个小项目标准库的代码量更小函数的调用关系更直接——你打开一个myi2c.c就能看到I2C时序的每一行代码答辩时老师问到底层原理你能讲得头头是道。用HAL库的话很多细节被封装掉了如果老师深挖HAL_I2C_Mem_Read内部做了什么你可能只答得出来调库这就尴尬了。我最终用的方案是用标准库但工程结构完全模仿HAL库的分层思想。也就是说main.c只做初始化调用和主循环外设驱动按模块拆分mpu6050.c、gps.c、gsm.c、oled.c每个模块提供清晰的接口函数。这样的好处是代码可读性高论文画架构图也方便。如果你想用CubeMX生成HAL库工程关键代码逻辑是一样的区别只在底层API名称。3.2 I2C读取MPU6050的完整代码流程MPU6050的I2C地址是0x68AD0引脚接地如果AD0接高则地址变为0x69。模块上电后先要解除休眠向寄存器0x6B写入0x00。我贴一段自己工程里的完整初始化代码#define MPU6050_ADDR 0xD0 // 左移一位后的地址用于标准库I2C写 #define MPU6050_ACCEL_XOUT_H 0x3B void MPU6050_Init(void) { I2C_WriteByte(MPU6050_ADDR, 0x6B, 0x00); // 解除休眠 I2C_WriteByte(MPU6050_ADDR, 0x1C, 0x18); // 加速度计量程 ±16g寄存器值为0b11000 I2C_WriteByte(MPU6050_ADDR, 0x1B, 0x18); // 陀螺仪量程 ±2000dps I2C_WriteByte(MPU6050_ADDR, 0x1A, 0x03); // 数字低通滤波带宽约44Hz I2C_WriteByte(MPU6050_ADDR, 0x19, 0x09); // 采样率分频实际约50Hz }读取加速度和角速度数据的核心函数void MPU6050_ReadData(int16_t *accel, int16_t *gyro) { uint8_t buf[14]; I2C_ReadBytes(MPU6050_ADDR, MPU6050_ACCEL_XOUT_H, buf, 14); accel[0] (buf[0] 8) | buf[1]; // Accel X accel[1] (buf[2] 8) | buf[3]; // Accel Y accel[2] (buf[4] 8) | buf[5]; // Accel Z gyro[0] (buf[8] 8) | buf[9]; // Gyro X gyro[1] (buf[10] 8) | buf[11]; // Gyro Y gyro[2] (buf[12] 8) | buf[13]; // Gyro Z }注意加速度计和陀螺仪的数据都是16位有符号数±16g量程下每LSB对应16/32768 0.000488g±2000dps量程下每LSB对应2000/32768 0.061dps。换算成物理量后合加速度和角速度的计算就很直接了。我用的是宏定义做换算避免代码里出现魔法数字#define ACCEL_LSB_TO_G(lsb) ((lsb) * 0.000488f) #define GYRO_LSB_TO_DPS(lsb) ((lsb) * 0.061f)3.3 用DMA配合定时器实现50Hz采样不占用CPU我最初写的是在主循环里轮询读MPU6050加上OLED刷新、GPS解析、GSM状态机循环周期很不稳定有时候20ms有时候50ms这会导致采样率不恒定的问题直接影响跌倒冲击判决的准确性。后来改成定时器2产生50Hz中断在中断服务函数里只做读传感器和缓存数据的动作主循环只做算法判断和业务逻辑。void TIM2_IRQHandler(void) { if (TIM_GetITStatus(TIM2, TIM_IT_Update) ! RESET) { TIM_ClearITPendingBit(TIM2, TIM_IT_Update); MPU6050_ReadData(accel_raw, gyro_raw); data_ready_flag 1; // 置位标志主循环发现该标志后取数据计算 } }主循环里检测到data_ready_flag后再做滤波、合加速度计算和状态机更新这样中断服务函数保持极短不会阻塞系统。串口调试方面我在工程里加了一个简单的printf重定向通过USART1输出调试信息格式类似[ACC] x0.21g y-0.08g z0.98g, sum1.001g, gyro_rms12.6dps [EVT] STATE_CHANGE: NORMAL - IMPACT, accel_sum2.87g [EVT] STATE_CHANGE: IMPACT - FALL_CONFIRMED, angle62.1, still1这套调试输出是整个项目后期调参的命脉一定要从开始就搭好。数据格式用固定前缀字段名方便用串口终端筛选。我踩过在串口助手里肉眼盯一堆数字的坑效率极低后来改成在代码里主动输出事件只有状态机跳变时才打印一行排查问题一目了然。3.4 ST-Link调试与程序下载的注意事项程序烧录用ST-Link V2通过SWD接口四根线SWDIO、SWCLK、GND、3.3V就够。我第一次画PCB时忘了把SWDIO和SWCLK引出来结果只能飞线调试非常痛苦。这里提醒一句STM32F103的PA13、PA14、PA15、PB3、PB4在上电默认复用为JTAG功能如果你把这三个引脚当普通GPIO用比如接按键、LED软件里必须禁用JTAG并释放引脚。否则你会发现程序下载成功但引脚怎么都不输出电平或者按键怎么读都是高。搜索热词里经常看到stm32禁用jtag就是这个原因。// 禁用JTAG保留SWD GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE);烧录工具我用的是ST-Link Utility也兼容后面要说的Flash读取和芯片解锁。如果遇到下载失败提示No target connected八成是目标板供电问题或者SWD线过长先检查这两点。芯片内部Flash的读写操作我还用在了掉电保存配置项上比如预设的家属电话号码、报警灵敏度阈值存到Flash最后几页这样修改设置后重启不丢。4. 跌倒检测算法在单片机上的落地实现4.1 从原始数据到是不是摔了完整的计算过程先说合加速度。设三轴加速度原始数据经过换算后分别为 \(a_x\)、\(a_y\)、\(a_z\)那么合加速度为[ a_{sum} \sqrt{a_x^2 a_y^2 a_z^2} ]静止站立时合加速度应该接近1g摔倒冲击瞬间会突然变大。这个量用来判断有没有发生剧烈冲击。然后是姿态角。俯仰角 \(\theta\) 和横滚角 \(\phi\) 可以通过加速度计的静态分量估算[ \theta \arctan2(a_x, \sqrt{a_y^2 a_z^2}) \times \frac{180}{\pi} ][ \phi \arctan2(a_y, \sqrt{a_x^2 a_z^2}) \times \frac{180}{\pi} ]注意这里的角度是相对于重力方向的倾斜角不是欧拉角定义里的完整姿态。对跌倒检测来说只要知道设备从接近竖直变成了接近水平就说明佩戴者的身体姿态发生了显著变化。状态机中我用姿态角度变化量来作为第二级判断条件每秒计算当前姿态角与跌倒前姿态角的差值如果差值超过45度且冲击条件也满足过就把状态推进到确认摔倒。实现代码float calc_accel_sum(int16_t *accel) { float ax accel[0] * ACCEL_LSB_TO_G(1); float ay accel[1] * ACCEL_LSB_TO_G(1); float az accel[2] * ACCEL_LSB_TO_G(1); return sqrtf(ax*ax ay*ay az*az); } float calc_pitch(int16_t *accel) { float ax accel[0] * ACCEL_LSB_TO_G(1); float ay accel[1] * ACCEL_LSB_TO_G(1); float az accel[2] * ACCEL_LSB_TO_G(1); if (az 0) az 0.001f; // 防止除零 return atan2f(ax, sqrtf(ay*ay az*az)) * 57.29578f; }4.2 状态机的完整实现与阈值参数标定我的状态机用枚举变量定义typedef enum { ST_NORMAL 0, ST_IMPACT, ST_CONFIRM_WAIT, ST_ALERT } FallState;状态机的驱动逻辑是每个采样周期20ms执行一次ST_NORMAL计算合加速度若超过ACCEL_IMPACT_TH 2.5g且角速度有效值超过GYRO_IMPACT_TH 200dps进入ST_IMPACT。ST_IMPACT记录当前时间继续观察后续100ms内的姿态角变化。如果姿态角变化量超过ANGLE_CHANGE_TH 45度进入ST_CONFIRM_WAIT如果只观察到冲击但没有姿态变化比如剧烈咳嗽、拍桌子回到ST_NORMAL。ST_CONFIRM_WAIT持续3秒150个采样周期累积统计这段时间内合加速度的标准差。如果标准差小于STILL_STD_TH 0.15g说明人体基本静止判定为严重跌倒进入ST_ALERT如果标准差较大说明老人摔倒后还能活动属于轻微跌倒也进入报警但报警级别降低。ST_ALERT触发蜂鸣器OLED显示提示如果5秒内按键没有取消就启动GSM短信电话报警。短信发送成功后状态机复位到ST_NORMAL。阈值参数怎么定我前期用了一组实验数据模拟正常走路、跑步、坐下、起身、弯腰、慢蹲、前倾跌倒、侧向跌倒、后仰跌倒。每种动作做20次记录合加速度峰值和姿态角变化。最终确定的阈值是在正常动作不触发和跌倒动作不漏报之间取平衡。这个实验过程和记录表格是论文里的重要论据强烈建议认真做答辩时老师非常看重。4.3 为什么要组合加速度冲击角度变化静止检测三个条件而不是只看一个老人跌倒最危险的情况不是摔倒这个动作本身而是摔倒后长时间得不到救助。如果系统只检测摔倒冲击那么对于老人摔倒后自己爬起来坐下的情况系统可能已经发了一条报警短信家属火急火燎赶过来发现虚惊一场。如果系统加上了摔倒后静止检测就能区分两种场景摔倒后随即恢复活动可能是滑倒后自行起身系统发短信通知家属但不必打电话。摔倒后持续静止系统不仅发短信还要自动拨打家属电话因为这种情况下老人大概率意识不清、无法主动求助。这个分级报警的设计让整个系统更像一个有逻辑的人而不是一个只会报数的传感器也让我在答辩时有了一个很完整的设计考量故事可以讲。4.4 一个典型误报案例的排查过程为什么坐下会触发报警项目中期联调时遇到一个诡异的问题老人正常坐到椅子上系统偶尔会报警。我用串口把每次状态机跳变的日志打出来发现坐下的瞬间合加速度确实达到了2.5g阈值——因为人从站立到坐下的过程中臀部撞到椅面给躯干带来了一次向上的冲击幅度完全不亚于慢速跌倒。后来我把合加速度阈值从2.5g提升到3.0g误报率下降了一些但蹲下捡东西还是会偶发误报。真正解决问题是在加了角速度有效值条件之后[ \omega_{rms} \sqrt{\frac{\omega_x^2 \omega_y^2 \omega_z^2}{3}} ]坐下这个动作虽然也有冲击但躯干旋转的剧烈程度远低于摔倒。实测坐下时角速度有效值通常在100dps以下而跌倒时普遍超过250dps。把角速度阈值设到200dps坐下这个动作就被排除掉了。单一阈值永远在灵敏度和误报率之间打架多维度组合才有效——这个经验在我后续做任何运动识别项目时都用得上。5. 报警与通知链路从本机蜂鸣到家属手机震动5.1 GSM模块AT指令实操发短信和打电话GSM模块我用SIM800C通过串口和STM32通信核心是AT指令。模块上电后需要等待约2到3秒的注册网络时间可以用ATCREG?查询是否注册成功返回CREG: 0,1表示已注册到网络。发送短信的指令序列是GSM_SendString(ATCMGF1\r\n); // 切换到文本模式 delay_ms(200); // 短信内容需要先把长度告诉模块 char cmd[64]; sprintf(cmd, ATCMGS\%s\\r\n, phone_number); GSM_SendString(cmd); delay_ms(500); GSM_SendString(ALERT! Old man fall detected!\r\n); GSM_SendString(Location: http://maps.google.com/maps?q); GSM_SendString(lat_str); GSM_SendString(,); GSM_SendString(lng_str); GSM_SendByte(0x1A); // CtrlZ 发送短信如果发送失败模块会返回ERROR我做了简单的超时重发机制最多重发3次每次间隔10秒。这个重发逻辑放在主循环的状态机里不能阻塞等待否则其他任务全部卡死。拨打电话更简单一行指令GSM_SendString(ATD8613800000000;\r\n); // 分号结尾表示只拨号不等待拨号后如果对方接听模块返回NO CARRIER表示通话结束。我还加了拨号后20秒自动挂断的逻辑避免电话一直响没人接浪费电量。5.2 串口不定长数据接收解析GPS的NMEA协议GPS模块通过串口持续输出NMEA 0183协议语句比如$GPRMC,080655.00,A,4546.40891,N,12639.65641,E,1.045,328.42,170813,,,A*60。我们要从中提取经纬度关键在于串口接收的是不定长数据——不能用固定缓冲区等着收完。推荐的做法是串口空闲中断IDLE判断一帧数据接收完成。HAL库的写法是void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart-Instance USART2) { gps_frame_len Size; gps_frame_ready 1; HAL_UARTEx_ReceiveToIdle_DMA(huart2, gps_buf, sizeof(gps_buf)); } }标准库没有现成的IDLE中断封装但我可以在USART2_IRQHandler里判断USART_IT_IDLE标志。具体来说当串口空闲时IDLE标志位会置1在中断里清标志并记录当前DMA接收位置就得到一帧完整的GPS数据。之后在主循环里用字符串搜索函数解析$GPRMC语句里的字段char *p strstr(gps_buf, $GPRMC); if (p ! NULL) { sscanf(p, $GPRMC,%d,%c,%lf,%c,%lf,%c,..., ...); }我把GPS解析函数封装成一个独立模块调用一次就更新全局的经纬度字符串。在室内没有GPS信号时经纬度保持上一次有效值并给OLED显示GPS: NO FIX提示。5.3 MQTT云平台方案作为进阶扩展点GSM短信是基础方案稳定可靠、演示效果直观。但有条件的话可以在论文里设计一个升级版用Air724UG或者ESP8266接入WiFi/4G通过MQTT协议把检测数据推送到云平台巴法云或者阿里云IoT手机App订阅同一个Topic就能实时收到报警。这套方案在答辩时展示App推送消息视觉效果比短信更现代化但工作量会多出至少一周。我个人的建议是先确保GSM链路跑通MQTT作为论文里的系统扩展设计章节写思路时间充裕再实现代码。不要一上来就两头抓最后的联调压力会非常大。6. 系统联调实录那些复现了三次才解决的坑6.1 MPU6050首次读取全零I2C上拉与地址确认第一次上电我用串口打印MPU6050的原始数据发现全是0。排查过程是这样的先量模块的VCC和GND3.3V正常。用示波器看SCL和SDA波形发现SCL有波形但SDA一直拉低。这其实说明I2C通信在SDA应答阶段卡住了。怀疑是I2C地址错误。GY-521模块上AD0引脚默认悬空但有些模块有下拉电阻有时候没焊好地址可能飘到0x69。最终发现是主控I2C与模块之间没有共地模块的GND和STM32的GND虽然都标着GND但因为我用杜邦线连接其中一根插错了孔导致两个设备参考地不一致I2C信号无法正确判断电平。这个坑很基础但很容易犯。后面我画PCB时把GND走线做成一个完整的地平面再也没遇到过通信异常。如果你用杜邦线做原型验证第一件事就是确认所有模块和主板共地。6.2 GSM模块发短信瞬间电压跌落导致系统重启这是整个项目中最隐蔽的一个坑。系统用锂电池供电待机时一切正常但当STM32下发指令让SIM800C发短信时屏幕突然黑屏程序从头跑。用万用表量VBAT电压发现瞬间跌落到3.0V以下。原因是GSM模块发射时瞬间电流达到2A电池电压被拉低STM32的电源也同时被拉低低于BOR复位阈值约2.4V芯片就复位了。解决方案分三层硬件层GSM模块的VBAT供电单独走线加一个1000uF的电解电容在模块电源附近做能量缓冲我实测能有效减小电压跌落幅度。另外从锂电到5V升压再到3.3V的路径每一级的压差都要考虑如果直接用AMS1117从电池电压做3.3V电池放电到3.6V时AMS1117可能已经无法输出稳定3.3V。软件层发短信前先通过GPIO控制GSM模块的PWRKEY引脚上电开机等待模块返回READY后再发AT指令。不要在系统刚上电、电池电压还没稳定时就发短信。逻辑层报警短信发送和蜂鸣器鸣叫不同步。蜂鸣器鸣叫的瞬间电流也有100mA级虽然不大但叠加在GSM模块的峰值上就是压垮骆驼的最后一根稻草。我把先发短信、后蜂鸣器响改成先蜂鸣器响100ms等电流稳定后再发短信系统重启问题就消失了。6.3 串口调试数据乱码波特率校准问题GPS模块默认波特率9600GSM模块默认也是9600STM32的USART1调试串口我用115200。如果波特率设置不对串口助手里看到的就是乱码。检查点时钟配置STM32F103的USART波特率由APB总线时钟决定如果CubeMX里时钟树配置到了64MHz而不是72MHz实际波特率会偏长时间传输数据后误差累积就会出现乱码。我遇到过APB1时钟是36MHzUSART2挂载在APB1上此时计算波特率时要除以2容易搞混。串口助手设置注意数据位、停止位、校验位是否和代码一致。默认8-N-1出错概率小但不能想当然。6.4 算法误报的现场调试用串口日志还原事件现场误报问题最怕的是抱着代码干瞪眼我习惯的做法是把MPU6050的原始数据以50Hz全部通过串口发到PC用串口工具录制到CSV文件然后在Python里画波形图。跌倒发生那段波形一看就明白到底是冲击阈值设太低了还是姿态角变化判据没生效一目了然。这个过程我强烈建议写进论文的系统调试章节它体现的是工程师的排障思路。7. OLED交互与本地提示不能只靠手机短信7.1 OLED数据刷新的优化避免阻塞主循环0.96寸OLED通过I2C刷新整屏需要大约30ms如果在主循环里每次都全量刷屏检测算法的实时性会受影响。我的做法是把OLED刷新拆成两档快速模式每200ms只刷新数字区域比如合加速度和状态显示利用SSD1306的页写入特性只需要重写几个页不重刷全屏。慢速模式每2秒更新一次完整界面包括GPS坐标等变化慢的信息。OLED的驱动我用的是纯软件I2C因为把I2C1给了MPU6050I2C2给了OLED两个外设不互相抢占总线。如果只有一个硬件I2C可以用软件模拟但要注意时序里加入适当延时否则OLED偶尔会花屏。7.2 三级报警策略什么时候响、什么时候发短信、什么时候打电话我把报警分成三级这个设计在论文里写出来非常加分一级提示合加速度超过阈值但状态机还没走完OLED显示检测到异常运动蜂鸣器短鸣一声100ms给老人自己一个我刚才动作有点猛的提示不打扰家属。二级报警状态机确认跌倒且老人3秒内有活动迹象。此时蜂鸣器持续鸣叫OLED显示摔倒按取消键同时发送短信给家属但不打电话。三级报警状态机确认跌倒且3秒内检测到静止无活动。蜂鸣器高频鸣叫OLED显示严重跌倒发送短信并自动拨打电话给家属。三级策略的价值在于给人为干预留出空间。老人感觉没事可以按键取消家属也不会因为一次弯腰就被吓到。这个设计在答辩中被评委问到的概率极高一定要能讲清楚每一级判定的数据依据。8. 论文结构规划与毕设资料整理经验8.1 论文章节怎么对应代码模块很多同学代码写完了论文却不知道从何写起。我的做法是自上而下对应系统需求分析 - 总体方案设计硬件选型、系统框图- 硬件详细设计各模块电路原理- 软件详细设计主程序流程、状态机、各外设驱动- 系统测试与结果分析阈值实验、误报率统计- 总结与展望。其中系统测试与结果分析是拉开分差的地方。我列出了测试表格比如动作类型测试次数触发系统报警次数报警准确率正常行走500100%不误报坐下50198%不误报弯腰捡物500100%不误报前向跌倒302893.3%检出侧向跌倒302996.7%检出这个表格里坐下动作偶尔误报的记录反而比全部是100%的成绩更可信因为真实系统不可能完美。我在论文里把那次误报的日志分析和阈值调整过程完整写了出来评委看到这个细节都觉得很有说服力。8.2 高分毕设资料的组织方式让别人能复现是最高级的展示我提交的全部资料除了源码和论文外还包括了Proteus仿真文件如果有Altium Designer格式的原理图PDF和PCB文件元器件清单BOM表带价格和购买链接烧录教程含OpenOCD脚本和ST-Link Utility截图演示视频链接屏幕录像包含跌倒模拟和短信接收画面答辩PPT任务书、开题报告、中期检查表的模板这些资料的价值不只是给老师看更是让后来者能按着你的文档一步步复现。我花了两天时间写了一套从零到一复现指南每个步骤都配上实物照片。后来这套资料被好几个学弟拿去参考他们说照着做一遍比看十篇论文都管用。毕设做的是工程不是玄学资料越完整越能体现你的系统工程能力。8.3 如果时间允许可以考虑的扩展方向心率血氧检测MAX30102模块通过I2C接到STM32摔倒后检测心率如果心率低于50bpm或高于150bpm可判断老人身体状况报警短信附带心率数据。这个扩展只需要增加一个传感器模块和100行代码但论文的系统扩展章节就非常丰满。GPS轨迹回放定时把经纬度存到SD卡或Flash家属可以在手机上查看老人一天的活动轨迹。这个扩展点可以和云平台方案结合。语音播报SYN6288语音合成模块跌倒后直接语音提示我已经通知您的家人给老人即时反馈比OLED提示更直观。低功耗设计STM32进入STOP模式用外部中断按键或跌倒冲击信号唤醒。这里就涉及STM32低功耗模式、RTC唤醒、GPIO外部中断唤醒等知识点工作量不大但能体现你对功耗的思考。我在做这个项目时最大的体会是选题不在新在于能不能把一个看起来简单的需求做扎实。传感器选型的技术对比、状态机的设计思路、GSM报警链路中让人头疼的电源稳定性问题每一个环节都有足够深入的工程细节可以挖掘。论文和代码只是载体真正的内核是你对如何可靠地判断老人摔倒并完成报警这件事的系统性思考。如果你正在做同题目的毕设建议先搭好串口调试日志和状态机框架再一步步调阈值、补全报警链路这个过程本身就能帮你积累大量的答辩素材。本文还有配套的精品资源点击获取 基于STM32与MPU6050的跌倒检测报警系统设计
简介本资源是一套完整的基于STM32的老人摔倒报警系统毕业设计项目面向电子信息、自动化、嵌入式相关专业本科生解决居家养老场景中老年人突发摔倒后及时报警与救助的核心需求适用于毕业设计、课程设计及期末大作业等实践环节。压缩包共338个文件涵盖76个C源码、68个头文件.h、48个编译中间文件.o/.d/.crf及Keil工程配置.uvprojx/.uvoptx、PCB原理图.schdoc、硬件设计文档.pdf、可执行固件.hex等全面支撑从代码开发、硬件调试到论文撰写的全流程包体大小为14.91MB。已有162人学习下载项目经助教审定、本地实测编译通过评审得分98分难度适中且结构清晰——含传感器数据采集、姿态判断算法、SIM900A短信报警模块驱动及低功耗管理等关键实现配套论文与完整资料可直接用于答辩与复现。 先说说这个项目的来龙去脉。老人摔倒报警装置在毕业设计里属于经典永流传的题目网上方案五花八门但真正能跑通、能复现、答辩能讲清楚的其实不多。我手头做过的这套基于STM32F103C8T6搭配MPU6050六轴传感器配合GPS定位GSM短信报警另加OLED显示和本地蜂鸣器硬件成本控制在百元上下功能覆盖了检测、定位、报警、确认四条完整链路。全文会从硬件选型逻辑、传感器数据采集、跌倒检测算法落地、报警联动机制到联调踩坑一条线讲完适合正在做毕设、或者想给家里老人做一套低成本守护方案的工程师参考。需要说明的是本文基于我实际调试中常用的标准库工程展开HAL库的写法差异我会在关键处标出方便你对着自己的工程改。1. 判断摔倒了这件事传感器到底在测什么1.1 为什么选择MPU6050六轴传感器而不是只用三轴加速度计很多同学一开始想省成本觉得用一个三轴加速度计ADXL345就够判断摔倒了。单看加速度幅值确实能捕捉到摔倒瞬间的冲击但问题在于老人摔倒后如果意识清醒会自己爬起来加速度波形和坐下、躺下、弯腰捡东西非常相似如果意识丧失倒地不动加速度输出又和正常睡觉差不多。只靠加速度一个维度误报和漏报都压不住。MPU6050内部集成了三轴加速度计和三轴陀螺仪可以同时输出加速度和角速度。摔倒过程有一个非常明显的特征姿态发生快速且大幅度的变化。加速度计捕捉冲击合加速度瞬间冲到2g甚至3g以上陀螺仪捕捉旋转角速度在短时间内超过某个阈值两者同时满足再去判断后续是否静止这套逻辑才是工程上可用的。我用的MPU6050模块是常见的GY-521小板板载稳压和I2C上拉电阻3.3V供电直接插杜邦线就能用。虽然模块本身有10位ADC精度但对于跌倒检测这种量级的事件完全够用。如果你想要更精确的姿态角输出可以用BMI160这种带硬件DMP的传感器但代码复杂度和成本都会上来毕设阶段没必要。1.2 跌倒检测的两大算法流派阈值法 vs 状态机阈值法最简单直观不断计算加速度矢量和 [\sqrt{x^2y^2z^2}]设定一个高阈值比如2.5g加速度超过阈值就认为发生了跌倒冲击。这个方法的优点是计算量小、STM32在每次采样间隔内轻松搞定缺点是无法区分老人摔倒和老人把手里东西重重摔在桌上这类冲击。所以实际项目里我做了改进冲击检测只是第一级冲击发生后紧接着检查角速度积分量也就是姿态角变化如果姿态角的改变超过45度且接下来3到5秒内加速度基本没有大幅波动判定为静止或缓慢活动才真正触发报警。这就是一个简单的状态机状态1正常活动合加速度和角速度都在阈值内状态2疑似摔倒合加速度超过冲击阈值状态3确认摔倒冲击后姿态角变化大且进入静止状态4报警触发蜂鸣器和短信通知为什么用状态机而不是直接阈值报警因为老人日常生活中弯腰、侧身、咳嗽都可能产生短暂的冲击状态机通过冲击后是否伴随大幅姿态变化这个条件把绝大多数伪摔倒排除掉了。我在实测中弯腰捡东西这个动作就不会触发报警因为虽然躯干前倾但角速度变化平缓姿态变化达不到摔的剧烈程度。1.3 采样率、滤波和安装位置三个容易被忽略的细节采样率方面MPU6050的加速度计输出速率最高可以到1kHz但我实际配置成50Hz20ms一次采样。跌倒冲击的持续时间大约在300到500ms50Hz采样率下能采到15到25个有效点足够捕获冲击峰值。更高的采样率会占用I2C总线时间和MCU计算资源反而没必要。陀螺仪的量程我设置成±2000dps加速度计量程设置成±16g因为跌倒瞬间角速度和加速度都可能远超日常活动范围量程设小了数据会削顶。滤波方面我用了最简单的滑动平均滤波取最近5次加速度数据的均值参与计算。这个滤波能平滑掉传感器噪声但不会模糊冲击峰值因为滑动窗口足够短。卡尔曼滤波虽然精度高但在STM32F103这种主频72MHz的芯片上算姿态角每个周期要多花好几毫秒对50Hz的采样来看还扛得住但对中断实时性要求高的场景不建议。安装位置我踩过一次坑。最初把模块随便贴在装置外壳中间后来发现不同佩戴位置的加速度波形差异明显绑在腰间和挂在胸前跌倒冲击的方向不一样合加速度的峰值也不同。实测下来绑在胸前或者腰间最稳定因为人体躯干在摔倒时是整体运动传感器能最直接地反映身体姿态变化。装在裤兜里则容易因为腿部动作幅度大产生大量误判建议不要在毕设文档里写这个位置。2. 硬件选型与系统框架一条完整的报警链路是怎么串起来的2.1 主控为什么选STM32F103C8T6而不是51或者ESP3251单片机做这个项目有个致命短板MPU6050的I2C通信虽然简单但51没有硬件I2C靠IO口模拟时序配合浮点运算计算合加速度和姿态角主频12MHz跑起来非常吃力。ESP32虽然性能强、自带WiFi和蓝牙但在毕设场景里裸跑裸调的难度比STM32大资料相对分散而且很多学校的嵌入式课程主线就是STM32答辩时老师对STM32的提问你更容易接住。STM32F103C8T6是Cortex-M3内核72MHz主频20KB RAM64KB Flash带硬件I2C、USART、SPI、ADC等外设。做这个项目RAM和Flash占用大约分别是5KB和30KB左右余量充足。最难得的是它的生态标准外设库、HAL库、LL库加上网上海量的例程任何一个模块的驱动都能找到参考。注意如果后续要加FreeRTOS或者跑LVGL这种人机交互界面建议换STM32F103RCT648KB RAM256KB Flash不然Flash会很紧张。我在这套方案里没有上OS裸机轮询定时器中断就够用了。2.2 定位与通信GPSGSM组合为什么比WiFi方案更贴合场景老人摔倒报警最怕的是什么摔倒后老人无法主动求助需要系统自动通知家属。这个场景对通信链路有两个要求一是覆盖范围广二是能主动触达。WiFi方案依赖家庭路由器老人在楼道、小区花园摔倒时根本没有网络覆盖BLE方案需要家属在附近也不现实。所以GSM/GPRS模块如SIM800C、SIM900A配合GPS模块如ATGM336H或NEO-6M才是真正贴合移动场景的组合。这套组合的工作逻辑是检测到摔倒后STM32先读GPS模块的经纬度、时间数据通过串口发送NMEA协议指令解析然后把预设的告警短信通过GSM模块发送到家属手机号短信内容带上坐标链接比如Google Maps链接。必要时还可以让GSM模块直接拨打家属电话——这个功能在老人失去意识无法接听时尤其重要家属看到来电号码就知道出事了。也有同学问用4G Cat.1模块比如Air724UG行不行当然行Cat.1模块内置了MQTT协议栈可以直接往云平台推数据方案更现代化但价格比GSM模块贵一倍且SIM卡需要开通物联网套餐毕设演示时要考虑学校环境有没有4G信号。我建议基础方案用GSM并在论文里提一句可平滑升级到Cat.1模块这是加分项而不是必选项。2.3 电源方案为什么不能用USB供电直接完事很多同学做完硬件往电脑USB口一插能跑就交差了。但老人摔倒报警装置是便携设备供电方案必须考虑。我分了三路电源主控和传感器用3.3V由AMS1117从5V降压得到GSM模块用4V左右供电SIM800C的VBAT范围是3.4到4.4V峰值电流可达2A必须单独供电GPS模块用3.3V市电供电不现实锂电池是主流。5000mAh的18650电池组两节并联配合充放电管理模块比如TP4056理论续航在GSM模块待机正常检测的场景下能撑一天甚至更久。但GSM模块在发短信时瞬间电流可以冲到1.5A以上如果电池内阻大或者走线细电压会被拉低直接导致模块重启。这个问题我后面专门用一个小节讲属于必须公开的坑。2.4 显示和交互OLED、按键、蜂鸣器的分工OLED我用的是0.96寸I2C接口的SSD1306用来显示当前姿态角、合加速度、系统状态和GPS定位信息这个界面主要是给调试用以及现场演示时让评委直观看到系统在实时检测。按键的作用是人工取消报警一旦系统进入报警状态会先蜂鸣器响同时OLED提示是否取消报警老人如果意识清醒在5秒内按下按键就能取消远程短信这是一个关键的防误报设计。蜂鸣器用的有源蜂鸣器三极管驱动STM32的IO口直接推不动。3. STM32工程搭建与传感器数据采集实战3.1 工程用标准库还是HAL库我的建议这两年HAL库CubeMX成了主流因为CubeMX图形化配置时钟、外设确实快生成的代码结构也规整。但说实话做这个小项目标准库的代码量更小函数的调用关系更直接——你打开一个myi2c.c就能看到I2C时序的每一行代码答辩时老师问到底层原理你能讲得头头是道。用HAL库的话很多细节被封装掉了如果老师深挖HAL_I2C_Mem_Read内部做了什么你可能只答得出来调库这就尴尬了。我最终用的方案是用标准库但工程结构完全模仿HAL库的分层思想。也就是说main.c只做初始化调用和主循环外设驱动按模块拆分mpu6050.c、gps.c、gsm.c、oled.c每个模块提供清晰的接口函数。这样的好处是代码可读性高论文画架构图也方便。如果你想用CubeMX生成HAL库工程关键代码逻辑是一样的区别只在底层API名称。3.2 I2C读取MPU6050的完整代码流程MPU6050的I2C地址是0x68AD0引脚接地如果AD0接高则地址变为0x69。模块上电后先要解除休眠向寄存器0x6B写入0x00。我贴一段自己工程里的完整初始化代码#define MPU6050_ADDR 0xD0 // 左移一位后的地址用于标准库I2C写 #define MPU6050_ACCEL_XOUT_H 0x3B void MPU6050_Init(void) { I2C_WriteByte(MPU6050_ADDR, 0x6B, 0x00); // 解除休眠 I2C_WriteByte(MPU6050_ADDR, 0x1C, 0x18); // 加速度计量程 ±16g寄存器值为0b11000 I2C_WriteByte(MPU6050_ADDR, 0x1B, 0x18); // 陀螺仪量程 ±2000dps I2C_WriteByte(MPU6050_ADDR, 0x1A, 0x03); // 数字低通滤波带宽约44Hz I2C_WriteByte(MPU6050_ADDR, 0x19, 0x09); // 采样率分频实际约50Hz }读取加速度和角速度数据的核心函数void MPU6050_ReadData(int16_t *accel, int16_t *gyro) { uint8_t buf[14]; I2C_ReadBytes(MPU6050_ADDR, MPU6050_ACCEL_XOUT_H, buf, 14); accel[0] (buf[0] 8) | buf[1]; // Accel X accel[1] (buf[2] 8) | buf[3]; // Accel Y accel[2] (buf[4] 8) | buf[5]; // Accel Z gyro[0] (buf[8] 8) | buf[9]; // Gyro X gyro[1] (buf[10] 8) | buf[11]; // Gyro Y gyro[2] (buf[12] 8) | buf[13]; // Gyro Z }注意加速度计和陀螺仪的数据都是16位有符号数±16g量程下每LSB对应16/32768 0.000488g±2000dps量程下每LSB对应2000/32768 0.061dps。换算成物理量后合加速度和角速度的计算就很直接了。我用的是宏定义做换算避免代码里出现魔法数字#define ACCEL_LSB_TO_G(lsb) ((lsb) * 0.000488f) #define GYRO_LSB_TO_DPS(lsb) ((lsb) * 0.061f)3.3 用DMA配合定时器实现50Hz采样不占用CPU我最初写的是在主循环里轮询读MPU6050加上OLED刷新、GPS解析、GSM状态机循环周期很不稳定有时候20ms有时候50ms这会导致采样率不恒定的问题直接影响跌倒冲击判决的准确性。后来改成定时器2产生50Hz中断在中断服务函数里只做读传感器和缓存数据的动作主循环只做算法判断和业务逻辑。void TIM2_IRQHandler(void) { if (TIM_GetITStatus(TIM2, TIM_IT_Update) ! RESET) { TIM_ClearITPendingBit(TIM2, TIM_IT_Update); MPU6050_ReadData(accel_raw, gyro_raw); data_ready_flag 1; // 置位标志主循环发现该标志后取数据计算 } }主循环里检测到data_ready_flag后再做滤波、合加速度计算和状态机更新这样中断服务函数保持极短不会阻塞系统。串口调试方面我在工程里加了一个简单的printf重定向通过USART1输出调试信息格式类似[ACC] x0.21g y-0.08g z0.98g, sum1.001g, gyro_rms12.6dps [EVT] STATE_CHANGE: NORMAL - IMPACT, accel_sum2.87g [EVT] STATE_CHANGE: IMPACT - FALL_CONFIRMED, angle62.1, still1这套调试输出是整个项目后期调参的命脉一定要从开始就搭好。数据格式用固定前缀字段名方便用串口终端筛选。我踩过在串口助手里肉眼盯一堆数字的坑效率极低后来改成在代码里主动输出事件只有状态机跳变时才打印一行排查问题一目了然。3.4 ST-Link调试与程序下载的注意事项程序烧录用ST-Link V2通过SWD接口四根线SWDIO、SWCLK、GND、3.3V就够。我第一次画PCB时忘了把SWDIO和SWCLK引出来结果只能飞线调试非常痛苦。这里提醒一句STM32F103的PA13、PA14、PA15、PB3、PB4在上电默认复用为JTAG功能如果你把这三个引脚当普通GPIO用比如接按键、LED软件里必须禁用JTAG并释放引脚。否则你会发现程序下载成功但引脚怎么都不输出电平或者按键怎么读都是高。搜索热词里经常看到stm32禁用jtag就是这个原因。// 禁用JTAG保留SWD GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE);烧录工具我用的是ST-Link Utility也兼容后面要说的Flash读取和芯片解锁。如果遇到下载失败提示No target connected八成是目标板供电问题或者SWD线过长先检查这两点。芯片内部Flash的读写操作我还用在了掉电保存配置项上比如预设的家属电话号码、报警灵敏度阈值存到Flash最后几页这样修改设置后重启不丢。4. 跌倒检测算法在单片机上的落地实现4.1 从原始数据到是不是摔了完整的计算过程先说合加速度。设三轴加速度原始数据经过换算后分别为 \(a_x\)、\(a_y\)、\(a_z\)那么合加速度为[ a_{sum} \sqrt{a_x^2 a_y^2 a_z^2} ]静止站立时合加速度应该接近1g摔倒冲击瞬间会突然变大。这个量用来判断有没有发生剧烈冲击。然后是姿态角。俯仰角 \(\theta\) 和横滚角 \(\phi\) 可以通过加速度计的静态分量估算[ \theta \arctan2(a_x, \sqrt{a_y^2 a_z^2}) \times \frac{180}{\pi} ][ \phi \arctan2(a_y, \sqrt{a_x^2 a_z^2}) \times \frac{180}{\pi} ]注意这里的角度是相对于重力方向的倾斜角不是欧拉角定义里的完整姿态。对跌倒检测来说只要知道设备从接近竖直变成了接近水平就说明佩戴者的身体姿态发生了显著变化。状态机中我用姿态角度变化量来作为第二级判断条件每秒计算当前姿态角与跌倒前姿态角的差值如果差值超过45度且冲击条件也满足过就把状态推进到确认摔倒。实现代码float calc_accel_sum(int16_t *accel) { float ax accel[0] * ACCEL_LSB_TO_G(1); float ay accel[1] * ACCEL_LSB_TO_G(1); float az accel[2] * ACCEL_LSB_TO_G(1); return sqrtf(ax*ax ay*ay az*az); } float calc_pitch(int16_t *accel) { float ax accel[0] * ACCEL_LSB_TO_G(1); float ay accel[1] * ACCEL_LSB_TO_G(1); float az accel[2] * ACCEL_LSB_TO_G(1); if (az 0) az 0.001f; // 防止除零 return atan2f(ax, sqrtf(ay*ay az*az)) * 57.29578f; }4.2 状态机的完整实现与阈值参数标定我的状态机用枚举变量定义typedef enum { ST_NORMAL 0, ST_IMPACT, ST_CONFIRM_WAIT, ST_ALERT } FallState;状态机的驱动逻辑是每个采样周期20ms执行一次ST_NORMAL计算合加速度若超过ACCEL_IMPACT_TH 2.5g且角速度有效值超过GYRO_IMPACT_TH 200dps进入ST_IMPACT。ST_IMPACT记录当前时间继续观察后续100ms内的姿态角变化。如果姿态角变化量超过ANGLE_CHANGE_TH 45度进入ST_CONFIRM_WAIT如果只观察到冲击但没有姿态变化比如剧烈咳嗽、拍桌子回到ST_NORMAL。ST_CONFIRM_WAIT持续3秒150个采样周期累积统计这段时间内合加速度的标准差。如果标准差小于STILL_STD_TH 0.15g说明人体基本静止判定为严重跌倒进入ST_ALERT如果标准差较大说明老人摔倒后还能活动属于轻微跌倒也进入报警但报警级别降低。ST_ALERT触发蜂鸣器OLED显示提示如果5秒内按键没有取消就启动GSM短信电话报警。短信发送成功后状态机复位到ST_NORMAL。阈值参数怎么定我前期用了一组实验数据模拟正常走路、跑步、坐下、起身、弯腰、慢蹲、前倾跌倒、侧向跌倒、后仰跌倒。每种动作做20次记录合加速度峰值和姿态角变化。最终确定的阈值是在正常动作不触发和跌倒动作不漏报之间取平衡。这个实验过程和记录表格是论文里的重要论据强烈建议认真做答辩时老师非常看重。4.3 为什么要组合加速度冲击角度变化静止检测三个条件而不是只看一个老人跌倒最危险的情况不是摔倒这个动作本身而是摔倒后长时间得不到救助。如果系统只检测摔倒冲击那么对于老人摔倒后自己爬起来坐下的情况系统可能已经发了一条报警短信家属火急火燎赶过来发现虚惊一场。如果系统加上了摔倒后静止检测就能区分两种场景摔倒后随即恢复活动可能是滑倒后自行起身系统发短信通知家属但不必打电话。摔倒后持续静止系统不仅发短信还要自动拨打家属电话因为这种情况下老人大概率意识不清、无法主动求助。这个分级报警的设计让整个系统更像一个有逻辑的人而不是一个只会报数的传感器也让我在答辩时有了一个很完整的设计考量故事可以讲。4.4 一个典型误报案例的排查过程为什么坐下会触发报警项目中期联调时遇到一个诡异的问题老人正常坐到椅子上系统偶尔会报警。我用串口把每次状态机跳变的日志打出来发现坐下的瞬间合加速度确实达到了2.5g阈值——因为人从站立到坐下的过程中臀部撞到椅面给躯干带来了一次向上的冲击幅度完全不亚于慢速跌倒。后来我把合加速度阈值从2.5g提升到3.0g误报率下降了一些但蹲下捡东西还是会偶发误报。真正解决问题是在加了角速度有效值条件之后[ \omega_{rms} \sqrt{\frac{\omega_x^2 \omega_y^2 \omega_z^2}{3}} ]坐下这个动作虽然也有冲击但躯干旋转的剧烈程度远低于摔倒。实测坐下时角速度有效值通常在100dps以下而跌倒时普遍超过250dps。把角速度阈值设到200dps坐下这个动作就被排除掉了。单一阈值永远在灵敏度和误报率之间打架多维度组合才有效——这个经验在我后续做任何运动识别项目时都用得上。5. 报警与通知链路从本机蜂鸣到家属手机震动5.1 GSM模块AT指令实操发短信和打电话GSM模块我用SIM800C通过串口和STM32通信核心是AT指令。模块上电后需要等待约2到3秒的注册网络时间可以用ATCREG?查询是否注册成功返回CREG: 0,1表示已注册到网络。发送短信的指令序列是GSM_SendString(ATCMGF1\r\n); // 切换到文本模式 delay_ms(200); // 短信内容需要先把长度告诉模块 char cmd[64]; sprintf(cmd, ATCMGS\%s\\r\n, phone_number); GSM_SendString(cmd); delay_ms(500); GSM_SendString(ALERT! Old man fall detected!\r\n); GSM_SendString(Location: http://maps.google.com/maps?q); GSM_SendString(lat_str); GSM_SendString(,); GSM_SendString(lng_str); GSM_SendByte(0x1A); // CtrlZ 发送短信如果发送失败模块会返回ERROR我做了简单的超时重发机制最多重发3次每次间隔10秒。这个重发逻辑放在主循环的状态机里不能阻塞等待否则其他任务全部卡死。拨打电话更简单一行指令GSM_SendString(ATD8613800000000;\r\n); // 分号结尾表示只拨号不等待拨号后如果对方接听模块返回NO CARRIER表示通话结束。我还加了拨号后20秒自动挂断的逻辑避免电话一直响没人接浪费电量。5.2 串口不定长数据接收解析GPS的NMEA协议GPS模块通过串口持续输出NMEA 0183协议语句比如$GPRMC,080655.00,A,4546.40891,N,12639.65641,E,1.045,328.42,170813,,,A*60。我们要从中提取经纬度关键在于串口接收的是不定长数据——不能用固定缓冲区等着收完。推荐的做法是串口空闲中断IDLE判断一帧数据接收完成。HAL库的写法是void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart-Instance USART2) { gps_frame_len Size; gps_frame_ready 1; HAL_UARTEx_ReceiveToIdle_DMA(huart2, gps_buf, sizeof(gps_buf)); } }标准库没有现成的IDLE中断封装但我可以在USART2_IRQHandler里判断USART_IT_IDLE标志。具体来说当串口空闲时IDLE标志位会置1在中断里清标志并记录当前DMA接收位置就得到一帧完整的GPS数据。之后在主循环里用字符串搜索函数解析$GPRMC语句里的字段char *p strstr(gps_buf, $GPRMC); if (p ! NULL) { sscanf(p, $GPRMC,%d,%c,%lf,%c,%lf,%c,..., ...); }我把GPS解析函数封装成一个独立模块调用一次就更新全局的经纬度字符串。在室内没有GPS信号时经纬度保持上一次有效值并给OLED显示GPS: NO FIX提示。5.3 MQTT云平台方案作为进阶扩展点GSM短信是基础方案稳定可靠、演示效果直观。但有条件的话可以在论文里设计一个升级版用Air724UG或者ESP8266接入WiFi/4G通过MQTT协议把检测数据推送到云平台巴法云或者阿里云IoT手机App订阅同一个Topic就能实时收到报警。这套方案在答辩时展示App推送消息视觉效果比短信更现代化但工作量会多出至少一周。我个人的建议是先确保GSM链路跑通MQTT作为论文里的系统扩展设计章节写思路时间充裕再实现代码。不要一上来就两头抓最后的联调压力会非常大。6. 系统联调实录那些复现了三次才解决的坑6.1 MPU6050首次读取全零I2C上拉与地址确认第一次上电我用串口打印MPU6050的原始数据发现全是0。排查过程是这样的先量模块的VCC和GND3.3V正常。用示波器看SCL和SDA波形发现SCL有波形但SDA一直拉低。这其实说明I2C通信在SDA应答阶段卡住了。怀疑是I2C地址错误。GY-521模块上AD0引脚默认悬空但有些模块有下拉电阻有时候没焊好地址可能飘到0x69。最终发现是主控I2C与模块之间没有共地模块的GND和STM32的GND虽然都标着GND但因为我用杜邦线连接其中一根插错了孔导致两个设备参考地不一致I2C信号无法正确判断电平。这个坑很基础但很容易犯。后面我画PCB时把GND走线做成一个完整的地平面再也没遇到过通信异常。如果你用杜邦线做原型验证第一件事就是确认所有模块和主板共地。6.2 GSM模块发短信瞬间电压跌落导致系统重启这是整个项目中最隐蔽的一个坑。系统用锂电池供电待机时一切正常但当STM32下发指令让SIM800C发短信时屏幕突然黑屏程序从头跑。用万用表量VBAT电压发现瞬间跌落到3.0V以下。原因是GSM模块发射时瞬间电流达到2A电池电压被拉低STM32的电源也同时被拉低低于BOR复位阈值约2.4V芯片就复位了。解决方案分三层硬件层GSM模块的VBAT供电单独走线加一个1000uF的电解电容在模块电源附近做能量缓冲我实测能有效减小电压跌落幅度。另外从锂电到5V升压再到3.3V的路径每一级的压差都要考虑如果直接用AMS1117从电池电压做3.3V电池放电到3.6V时AMS1117可能已经无法输出稳定3.3V。软件层发短信前先通过GPIO控制GSM模块的PWRKEY引脚上电开机等待模块返回READY后再发AT指令。不要在系统刚上电、电池电压还没稳定时就发短信。逻辑层报警短信发送和蜂鸣器鸣叫不同步。蜂鸣器鸣叫的瞬间电流也有100mA级虽然不大但叠加在GSM模块的峰值上就是压垮骆驼的最后一根稻草。我把先发短信、后蜂鸣器响改成先蜂鸣器响100ms等电流稳定后再发短信系统重启问题就消失了。6.3 串口调试数据乱码波特率校准问题GPS模块默认波特率9600GSM模块默认也是9600STM32的USART1调试串口我用115200。如果波特率设置不对串口助手里看到的就是乱码。检查点时钟配置STM32F103的USART波特率由APB总线时钟决定如果CubeMX里时钟树配置到了64MHz而不是72MHz实际波特率会偏长时间传输数据后误差累积就会出现乱码。我遇到过APB1时钟是36MHzUSART2挂载在APB1上此时计算波特率时要除以2容易搞混。串口助手设置注意数据位、停止位、校验位是否和代码一致。默认8-N-1出错概率小但不能想当然。6.4 算法误报的现场调试用串口日志还原事件现场误报问题最怕的是抱着代码干瞪眼我习惯的做法是把MPU6050的原始数据以50Hz全部通过串口发到PC用串口工具录制到CSV文件然后在Python里画波形图。跌倒发生那段波形一看就明白到底是冲击阈值设太低了还是姿态角变化判据没生效一目了然。这个过程我强烈建议写进论文的系统调试章节它体现的是工程师的排障思路。7. OLED交互与本地提示不能只靠手机短信7.1 OLED数据刷新的优化避免阻塞主循环0.96寸OLED通过I2C刷新整屏需要大约30ms如果在主循环里每次都全量刷屏检测算法的实时性会受影响。我的做法是把OLED刷新拆成两档快速模式每200ms只刷新数字区域比如合加速度和状态显示利用SSD1306的页写入特性只需要重写几个页不重刷全屏。慢速模式每2秒更新一次完整界面包括GPS坐标等变化慢的信息。OLED的驱动我用的是纯软件I2C因为把I2C1给了MPU6050I2C2给了OLED两个外设不互相抢占总线。如果只有一个硬件I2C可以用软件模拟但要注意时序里加入适当延时否则OLED偶尔会花屏。7.2 三级报警策略什么时候响、什么时候发短信、什么时候打电话我把报警分成三级这个设计在论文里写出来非常加分一级提示合加速度超过阈值但状态机还没走完OLED显示检测到异常运动蜂鸣器短鸣一声100ms给老人自己一个我刚才动作有点猛的提示不打扰家属。二级报警状态机确认跌倒且老人3秒内有活动迹象。此时蜂鸣器持续鸣叫OLED显示摔倒按取消键同时发送短信给家属但不打电话。三级报警状态机确认跌倒且3秒内检测到静止无活动。蜂鸣器高频鸣叫OLED显示严重跌倒发送短信并自动拨打电话给家属。三级策略的价值在于给人为干预留出空间。老人感觉没事可以按键取消家属也不会因为一次弯腰就被吓到。这个设计在答辩中被评委问到的概率极高一定要能讲清楚每一级判定的数据依据。8. 论文结构规划与毕设资料整理经验8.1 论文章节怎么对应代码模块很多同学代码写完了论文却不知道从何写起。我的做法是自上而下对应系统需求分析 - 总体方案设计硬件选型、系统框图- 硬件详细设计各模块电路原理- 软件详细设计主程序流程、状态机、各外设驱动- 系统测试与结果分析阈值实验、误报率统计- 总结与展望。其中系统测试与结果分析是拉开分差的地方。我列出了测试表格比如动作类型测试次数触发系统报警次数报警准确率正常行走500100%不误报坐下50198%不误报弯腰捡物500100%不误报前向跌倒302893.3%检出侧向跌倒302996.7%检出这个表格里坐下动作偶尔误报的记录反而比全部是100%的成绩更可信因为真实系统不可能完美。我在论文里把那次误报的日志分析和阈值调整过程完整写了出来评委看到这个细节都觉得很有说服力。8.2 高分毕设资料的组织方式让别人能复现是最高级的展示我提交的全部资料除了源码和论文外还包括了Proteus仿真文件如果有Altium Designer格式的原理图PDF和PCB文件元器件清单BOM表带价格和购买链接烧录教程含OpenOCD脚本和ST-Link Utility截图演示视频链接屏幕录像包含跌倒模拟和短信接收画面答辩PPT任务书、开题报告、中期检查表的模板这些资料的价值不只是给老师看更是让后来者能按着你的文档一步步复现。我花了两天时间写了一套从零到一复现指南每个步骤都配上实物照片。后来这套资料被好几个学弟拿去参考他们说照着做一遍比看十篇论文都管用。毕设做的是工程不是玄学资料越完整越能体现你的系统工程能力。8.3 如果时间允许可以考虑的扩展方向心率血氧检测MAX30102模块通过I2C接到STM32摔倒后检测心率如果心率低于50bpm或高于150bpm可判断老人身体状况报警短信附带心率数据。这个扩展只需要增加一个传感器模块和100行代码但论文的系统扩展章节就非常丰满。GPS轨迹回放定时把经纬度存到SD卡或Flash家属可以在手机上查看老人一天的活动轨迹。这个扩展点可以和云平台方案结合。语音播报SYN6288语音合成模块跌倒后直接语音提示我已经通知您的家人给老人即时反馈比OLED提示更直观。低功耗设计STM32进入STOP模式用外部中断按键或跌倒冲击信号唤醒。这里就涉及STM32低功耗模式、RTC唤醒、GPIO外部中断唤醒等知识点工作量不大但能体现你对功耗的思考。我在做这个项目时最大的体会是选题不在新在于能不能把一个看起来简单的需求做扎实。传感器选型的技术对比、状态机的设计思路、GSM报警链路中让人头疼的电源稳定性问题每一个环节都有足够深入的工程细节可以挖掘。论文和代码只是载体真正的内核是你对如何可靠地判断老人摔倒并完成报警这件事的系统性思考。如果你正在做同题目的毕设建议先搭好串口调试日志和状态机框架再一步步调阈值、补全报警链路这个过程本身就能帮你积累大量的答辩素材。本文还有配套的精品资源点击获取