做毕设那年实验室里已经有两个人做过温湿度计还有一个在做智能台灯。我拿到智能婴儿床这个题目的时候第一反应是这不就是把温湿度计、小夜灯、电机和蜂鸣器打包塞进一个木头框子里吗等真正动手才发现完全不是这么回事。婴儿床这个场景对系统的要求和你平时做的那些采集-显示-报警三件套完全不一样它需要在无人看管的情况下连续运行几个小时不出错传感器的任何一个误报都会让整晚睡不好电机的每一次异响都会让家长直接拔电源。而这些东西恰恰是STM32这类单片机最擅长、也最容易做砸的地方。这篇内容我打算把整个项目的实现过程拆开讲一遍从选题动机、主控和传感器选型到软件架构怎么搭、哭声识别怎么调、稳定性怎么保、论文和答辩怎么准备。适合正在做单片机方向毕业设计的同学也适合已经写过几版代码但系统在演示时总出状况的人。我会把那些文档里不会写、但实际调试时一定会遇到的问题讲清楚包括参数为什么这么定、坑是怎么踩出来的、以及我最后是怎么绕过去的。1. 为什么智能婴儿床在单片机毕设里算性价比之选1.1 从选题动机开始说功能边界比功能数量重要得多选这个题的人多数心里其实是有点发虚的。因为智能XX系统这个说法太宽了宽到你可以往里塞任何东西。我见过有人列了十几项功能温湿度、哭声识别、自动摇摆、尿湿检测、体重记录、蓝牙APP、远程视频、语音对话、音乐播放、自动喂奶提醒。听起来很唬人但真正落到答辩现场老师只要问一句尿湿检测的传感器你怎么贴在婴儿身上、安全性怎么保证基本上就答不上来了。我的建议是先定边界再定功能。婴儿床这个载体能承载的功能本质上分成四类环境监测类温度、湿度、空气质量。这类传感器便宜、成熟、好写论文。状态感知类声音哭声、体动、称重。这类传感器需要信号处理是技术含量所在。执行输出类摇摆、暖风、夜灯、播放。这类是能看出效果的部分演示时最抓眼球。交互通信类本地显示、按键、手机端。这类决定用户体验。一个能扛住答辩的配置我建议控制在每类挑一到两个总共八到十个功能点。功能少不代表简单把哭声识别做扎实比堆五个一知半解的模块有价值。老师问深度的时候你有东西可讲问广度的时候你也能覆盖全链路。1.2 主控到底选STM32还是STC先把这个问题想清楚热词里能看到大量关于STC、51单片机的讨论也有大量关于STM32的。这两个路线都能做出来但做出来的东西完全是两个样。对比项51/STC单片机STM32F103STM32F407主频12~35MHz72MHz168MHz浮点运算无全靠软件模拟无单精度硬件FPU定时器/PWM通道少复用麻烦充足4个通用定时器更多含高级定时器做FFT的能力基本别想可以做靠CMSIS-DSP轻松1024点无压力开发资料多但散乱极多生态成熟比F103少一些课程设计定位够用主流有余量如果你的系统里只有温湿度采集和继电器控制51单片机完全够代码量还小。但一旦要上哭声的频域分析、要跑RTOS做多任务、要用DMA搬ADC数据51就直接卡死了——它没有足够的RAM做缓冲也没有足够的算力在实时约束下跑FFT。我的选择是STM32F103C8T6理由有三条。第一72MHz主频配合CMSIS-DSP库做256点定点FFT大约几百微秒对8kHz采样的音频流完全够用。第二外设齐全ADC、I2C、SPI、USART、定时器都能同时开工不打架。第三也是最现实的资料多。江科大那套入门教程、正点原子的库函数版、HAL库的官方例程随手一搜就是一堆遇到问题能搜到答案的概率远高于冷门型号。至于F407除非你要做视频级处理或者需要硬件浮点跑复杂滤波否则对一个婴儿床系统来说是浪费。多花的那几十块钱和翻倍的调试时间不如投到传感器质量上。1.3 一份能被答辩老师认可的功能清单我把最终定下来的功能列一下后面几章都会围绕它展开。环境温度采集精度±0.3℃、湿度采集、显示与阈值报警。状态哭声检测频域识别不是简单的声音大小阈值、床体压力监测判断是否有人/翻身。执行电机驱动的轻度摇摆速度可调、定时停止、暖光夜灯、提示音播放。交互OLED本地显示 按键设置 手机端状态查看。可靠性独立看门狗、异常复位记录、传感器断线检测。这份清单乍看很常规但每一项我都标了精度或者实现方式。答辩的时候你把这些具体数字说出来和只说我能测温度得到的评价完全不一样。老师对我知道自己做到什么程度这件事比对功能很多更买账。2. 硬件链路从传感器到执行器的每一段电路2.1 感知层选型别让最便宜的元件拖垮整个系统温度湿度。DHT11是最常见的入门选择但它有两个致命问题一是响应慢两次读取间隔至少要1秒二是精度差温度±2℃、湿度±5%RH对于要判断是不是该给婴儿加被子的场景这个误差太大。我最终换成了SHT30I2C接口温度精度±0.3℃、湿度±3%RH还带CRC校验能把坏数据直接筛掉。价格贵了十来块钱但论文里写数据的时候底气完全不一样。声音。哭声检测是整个项目最关键、也最容易翻车的地方。很多人的做法是拿一个LM393比较器模块输出数字高低电平声音大就报警。这个方案的误报率高得离谱——关门的震动、外面的汽车、甚至风扇的气流都能触发。我改用MAX9814麦克风模块它自带AGC自动增益控制和可调增益输出的是模拟信号可以接STM32的ADC做进一步处理。这一步是从能用到可信的分水岭。压力/体动。我用的是电阻应变片加HX711的方案四个应变片贴在床板支撑点HX711做24位ADC采集采样率设成10Hz。这样既能测出大概重量用于判断是否有婴儿又能在翻身时观察到压力的剧烈波动。注意HX711的数据跳动很大原始值波动可能有几百个计数必须做滤波具体在第3章讲。人体存在。微波雷达模块常见的24GHz或者5.8GHz方案可以做非接触式检测但要注意它的穿透性和误触。我最终没把它作为主判据只作为一个辅助开关——检测到有人靠近自动点亮夜灯。2.2 执行层电机、驱动和隔离这三件事的顺序不能颠倒摇摆这部分看着简单实际上坑最多。先说电机选型。玩具级的小型减速电机便宜但它的问题是启动电流大、转速控制粗糙、低速时有明显的齿槽抖动。用PWM调速的时候如果频率选在音频范围会听到刺耳的啸叫——这一点在婴儿床场景里是绝对不允许的。我把PWM频率定在20kHz以上超出人耳听觉敏感区间配合电机两端并联的100nF陶瓷电容噪声基本消失。频率和噪声的关系是低于8kHz会听到低频嗡鸣8k到16k之间最刺耳20kHz以上基本听不见但频率太高会增加MOS管的开关损耗所以20kHz是个平衡点。驱动芯片用TB6612FNG双通道H桥单通道持续电流1.2A、峰值3.2A够用。它比L298N好在效率高、发热小、体积小。写代码时要注意TB6612的STBY引脚必须拉高才能工作我第一次调试时忘了这个对着PWM波形看了半小时没找出问题。继电器控制暖风或大功率负载的时候一定要加隔离。我的做法是STM32的GPIO → 光耦PC817→ 三极管 → 继电器线圈同时继电器线圈两端反向并一个1N4007做续流。为什么必须这么做因为继电器线圈断电瞬间会产生几百伏的反向尖峰这个尖峰如果传导回单片机轻则IO口锁死重则直接击穿。加一个二极管成本几分钱不加可能要换一块板子。2.3 电源设计这是全项目最容易被忽略、也最容易翻车的部分大部分同学的电源方案是一个12V适配器然后LM2596降到5V再AMS1117降到3.3V。这个链路本身没问题但细节决定成败。12V到5VLM2596是开关电源输出纹波大必须加大容量电解电容我用了470uF加小容量陶瓷电容100nF并联前者滤低频、后者滤高频。如果只加电解电容高频纹波照样能窜进ADC参考电压。5V到3.3VAMS1117是线性LDO效率低但纹波小。它的发热要注意如果后级电流超过300mA最好加个小散热片或者换成更高效的方案。模拟部分单独供电ADC采集声音和压力信号对电源干净程度很敏感。我在3.3V后面加了一级LC滤波10uH电感 10uF电容专门供给模拟部分。地线处理数字地和模拟地要分开走最后在电源入口处单点连接。如果直接大面积铺铜连在一起电机的开关噪声会通过地平面耦合到ADC里你会看到采集到的压力值随电机转速跳动。注意所有涉及婴儿接触的电气部分都要考虑漏电和过热风险。执行机构的机械结构建议由有经验的人设计或直接采用成熟成品软件部分只负责控制逻辑不要在毕业论文里承诺任何安全防护类的功能那超出了单片机的职责范围。2.4 原理图评审时我必看的几个固定动作板子打样之前我一定会对着原理图做这几件事检查每个IC的电源引脚是否有0.1uF去耦电容且尽量靠近引脚。缺一个调试时可能就是莫名奇妙的随机死机。检查所有上拉电阻。I2C的SDA/SCL必须上拉一般是4.7kΩ按键、复位、BOOT引脚也都要确认。检查BOOT0和BOOT1的默认电平。BOOT0接了10k下拉到地才能正常从Flash启动我第一次打板忘了这个下载完程序不运行查了半天。检查晶振和负载电容。8MHz晶振配20pF负载电容是常见搭配但如果你的芯片手册建议别的值以手册为准。检查ADC输入端的电压范围。STM32的ADC参考电压是3.3V输入信号必须在这个范围内。MAX9814的输出偏置在VDD/2附近如果供电是5V输出会在2.5V上下摆动超过3.3V会烧ADC。我用3.3V给麦克风供电输出的直流偏置就在1.65V摆幅安全。3. 软件架构裸机大循环还是上FreeRTOS3.1 任务该怎么切我为什么把采样和控制彻底分开先说结论这个系统我用了FreeRTOS。裸机大循环能不能做能。但我试过之后放弃了原因是时序冲突。哭声检测需要ADC以8kHz连续采样中间不能断摇摆控制需要精确的PWM占空比更新也不能被长时间打断显示刷新和按键扫描虽然不急但也不能完全不响应。如果全塞在一个while循环里你得手工安排每个函数的时间片一旦加入新的通信功能整个时序就乱了。用RTOS之后任务划分是这样的任务名优先级周期/触发方式职责AudioTask4最高由DMA半满/全满中断触发处理音频缓冲做FFT与判别ControlTask320ms周期摇摆PWM计算、执行器状态机SensorTask2100ms周期温湿度、压力采集与滤波CommTask2事件触发串口/WiFi收发协议解析UiTask1200ms周期OLED刷新、按键处理WatchTask0最低500ms周期喂狗、检查各任务心跳关键点在于音频任务优先级最高因为它有硬实时要求控制任务次之20ms的周期对应50Hz足够平滑通信和UI可以容忍延迟。如果反过来把UI放最高你会看到刷新屏幕的时候声音检测丢数据。3.2 ADC采样与滤波把跳变值压下去的具体做法传感器数据不干净是这个项目的常态。我分别说说三类信号的处理。温湿度。SHT30本身输出就比较稳但偶尔会有单点异常值。我的做法是连续读三次去掉最高最低取中间值然后再和一个长度为8的滑动窗口平均值做加权。为什么不直接用滑动平均因为滑动平均对突变的响应太慢万一传感器真的故障了你还在输出历史均值。中值滤波能快速剔除野值滑动平均负责平滑。压力HX711。这个噪声最大。原始数据在静止状态下可能有±200个计数的抖动。我用了两级处理第一级是长度为16的滑动平均把高频抖动压下去第二级是变化率检测如果相邻两次滤波后的差值超过设定阈值就判定为体动事件而不是噪声单独记录下来。这样既能得到稳定的重量读数又能捕捉到翻身动作。音频。8kHz采样率、256点一帧帧与帧之间重叠50%。先做直流去除减掉当前帧的均值再乘汉宁窗然后调用CMSIS-DSP的arm_rfft_fast_f32做实数FFT。得到频谱之后计算两个频带的能量比低频带300~800Hz哭声基频区高频带1500~4000Hz哭声的谐波和摩擦音区。婴儿哭声在这两个频带都有明显能量而大多数环境噪声只集中在低频。// 关键判据伪代码实际用定点运算 energy_low sum(|X[k]|^2), k 对应 300~800Hz energy_high sum(|X[k]|^2), k 对应 1500~4000Hz ratio energy_high / (energy_low 1e-6f) if (energy_low TH_LOW ratio 0.35f) { cry_frame_count; } else { cry_frame_count 0; } if (cry_frame_count 6) { // 约0.2秒的连续判定 trigger_cry_alarm(); }3.3 PWM驱动摇摆电机频率、占空比和死区时间的关系摇摆的舒适度取决于三个参数频率、幅度、加速度。频率上婴儿安抚类的摆动一般在0.5~1.5Hz之间也就是每分钟30到90次。太快会有眩晕感太慢没有安抚效果。我用的是1Hz作为默认值通过按键可以在0.6~1.2Hz之间调节。幅度通过电机的运行时长来控制一个周期内电机正转x毫秒、停y毫秒、反转x毫秒、停y毫秒。x越大摆幅越大但x超过一定值之后机械结构会顶到限位所以在软件里必须做上限保护。加速度是最容易被忽略的。如果你直接让PWM从0跳到满占空比机械结构会有明显的冲击感而且电机启动电流是额定电流的好几倍对电源是个考验。我加了一个软启动占空比在200ms内从0线性升到目标值。这个改动让整个机构的噪音和震动明显下降。死区时间的处理如果用的是H桥驱动正反转要确保正转和反转之间有一个短暂的停止间隔否则H桥上下桥臂可能瞬间同时导通直接烧管子。我的做法是状态机里强制插入50ms的停止态这个时间肉眼看不出来但对电路是保命的。3.4 显示与交互OLED、串口屏和按键的取舍本地显示我选了0.96寸的SSD1306 OLEDI2C接口128x64分辨率。理由是很简单便宜、驱动成熟、刷新快。缺点是屏幕小中文显示需要自己取模。如果不想折腾取模可以用串口屏它内部有字库一条串口指令就能显示中文代价是贵一些、体积大一些。按键我用的是三个独立按键加一个旋转编码器。旋转编码器用来调参数比如温度阈值、摇摆速度体验比反复按加减小按键好很多。编码器要注意消抖我用的是定时器中断里读A/B相位做四倍频计数比在GPIO外部中断里做要可靠。这里插一个关于延时函数的坑热词里也有人在问STM32延时函数delay卡死。典型场景是这样的你在某个中断服务函数里调用了依赖SysTick的延时比如HAL_Delay而这个中断的优先级比SysTick中断高SysTick中断进不来计数器永远不更新程序就死在那里了。解决办法有两个一是中断里绝对不要用基于SysTick的阻塞延时改用定时器计数或者简单的空循环二是把SysTick的中断优先级设到最高。我建议两者都做。3.5 通信协议一套够用就好的帧格式手机端查看状态我走的是WiFi模块ESP8266类。协议没必要搞得太复杂我用的是自定义帧帧头0xAA 0x55 长度1字节payload长度 命令1字节 数据N字节 校验1字节前面所有字节异或解析的时候注意两点。第一必须做超时处理如果收到帧头之后500ms内没凑齐完整帧就丢弃重新找帧头否则一旦丢一个字节后面全部错位。第二接收缓冲区要够大并且做环形结构防止数据来得比处理得快导致溢出。另外提醒一句Keil的安装有个小坑MDK和C51如果装到同一个目录下可能出现工具链冲突。我自己是把它们装在不同路径下用哪个开哪个省得折腾。4. 哭声识别从误报到可用的完整调试链路4.1 先认清声音传感器的真实能力边界我在这一块浪费的时间最多所以单独拿一章讲。先说一个反直觉的结论单纯用声音大不大来判断哭声是注定失败的。因为婴儿床通常放在卧室而卧室里的环境噪声波动范围极大——安静的夜里底噪可能只有30dB而有人在旁边说话时瞬间能到60dB。如果你把阈值定在45dB夜里安静时稍微有点响动就报警定在55dB白天就完全不响应。这个矛盾靠调阈值是解决不了的。频域分析之所以有效是因为它引入了一个声音听起来像不像哭的判据而不只是响不响。这是从一维判断变成二维判断可用性会有质的变化。但也要认清它的边界。麦克风模块的拾音范围有限如果婴儿床和你的调试台距离两米以上信号衰减会很严重。我做测试时会先把模块固定在实际安装位置而不是拿在手上调参数——拿在手上调出来的阈值装上去一定不对。4.2 阈值是调出来的不是算出来的我的三步法第一步采集底噪。让环境保持正常状态风扇开着、有人小声说话、窗户外有车经过连续采集5分钟记录每一帧的energy_low值取95百分位作为底噪上限。为什么取95百分位而不是最大值因为最大值可能来自一次偶发的关门声用它做阈值会让系统太迟钝。第二步采集真实哭声。这一步比较麻烦你总不能真的弄个婴儿来实验室。我的办法是找网上的婴儿哭声录音用手机在同样的距离播放。虽然和真实哭声有差异但频域特征基本一致。采集10段不同强度、不同时长的哭声记录energy_low和ratio的分布。第三步找分离点。把底噪和哭声的两组数据画在同一张图上你会看到它们在某些维度上有重叠但在另一些维度上分得很开。我的实测数据里ratio这个指标的分辨能力最强底噪的ratio大多在0.1~0.25之间哭声的ratio大多在0.4~0.7之间。所以我把ratio的阈值定在0.35energy_low的阈值定在底噪95百分位的1.8倍。4.3 多传感器融合怎么把误报率再压一个数量级即便做了频域分析还是会有误报主要来源是电视里的哭声、门外的婴儿、以及某些持续性的中高频噪声比如某些吸尘器。我加了两个辅助判据。一是持续时间真实哭声不会是一帧两帧通常会持续几秒。所以我把判定改为连续6帧满足条件才触发相当于0.2秒的验证窗口一下子就把大部分瞬时噪声挡掉了。二是压力传感器的联动如果压力传感器显示床上有负载并且有轻微体动哭声的可信度就更高如果床上根本没人即使检测到哭声也只记录不报警。这个逻辑很简单但对误报率的改善非常明显。方案底噪误报次/8小时真实哭声检出率单纯幅度阈值15~30约70%频域比值判据4~8约85%频域 连续帧验证1~3约85%频域 连续帧 压力联动0~1约88%数据是我自己实测的样本不算大但趋势很明确。注意检出率没怎么提升——因为有些哭声太轻麦克风确实拾不到。这属于硬件限制不是算法能解决的论文里如实写就行反而显得严谨。4.4 调试过程中踩过的几个具体坑第一个坑ADC采样率对不上。我一开始用定时器触发ADC、DMA搬运配置的是8kHz但实测发现频谱整体偏移。查了半天发现是定时器的重装载值算错了——我用了72MHz的时钟预分频设成72以为得到1MHz实际要减1才是正确值导致实际采样率是8.1kHz而不是8kHz。0.1kHz的偏差在时域看不出来但在频域会让1kHz处的频率偏移12.5Hz接近一个频率分辨率的距离。后来我把采样率反向验证了一遍喂一个已知频率的正弦波进去看峰值落在哪个bin算出来的频率和理论值对上才算配置正确。第二个坑FFT点数选得不合适。一开始用64点频率分辨率是125Hz300Hz和800Hz这两个频带只覆盖了4个bin能量统计完全不准。改成256点之后分辨率31.25Hz频带内有十几个bin统计才稳定。但256点也意味着每次处理需要更多的CPU时间所以我把采样率降到8kHz哭声的能量主要在4kHz以下这样一帧是32ms处理时间大约200微秒占用率不到1%。这个账要算清楚不然音频任务会挤占其他任务的时间。第三个坑缓冲区溢出。音频任务优先级高但它处理一帧的时间里DMA又攒了半帧数据。如果处理逻辑写得太慢就会出现覆盖。我的解决办法是开双缓冲DMA填充缓冲区A的时候任务处理缓冲区B通过半满和全满中断来切换。这样只要处理时间小于一帧的采集时间32ms就不会丢数据。第四个坑麦克风增益设得太高。MAX9814有一个GAIN引脚可以设置增益40dB/50dB/60dB。我一开始图省事接成60dB结果稍微有点声音就削顶波形全是平的频域分析完全失效。改成50dB之后正常说话不会削顶而哭声因为声压高仍然有足够的幅度。这个经验是增益要按最大预期信号来设而不是按最小信号。宁可小信号时信噪比差一点也不能大信号时削顶失真。5. 让系统从能跑走到敢演示5.1 看门狗不是加个喂狗就完事加独立看门狗IWDG是标配但很多人加的方式有问题随便找个地方喂狗。这样一旦某个任务卡死只要喂狗那个地方还在跑看门狗就永远不触发系统实际上已经失去响应了。我的做法是用一个心跳机制。每个任务在自己的循环里更新一个全局的计数器快照最低优先级的WatchTask每500ms检查一次如果某个任务的计数器在两次检查之间没有变化说明它卡住了这时就停止喂狗让IWDG复位系统。IWDG的超时时间我设成2秒比WatchTask的检查周期长但比人能忍受的卡死时间短。复位之后我在Flash的一个固定地址写一个标志和复位次数。上电时读出来如果是异常复位就在OLED上显示系统已重启同时把复位原因记录下来通过WiFi上报。这个小功能在答辩演示的时候特别好用——你可以现场模拟一次任务卡死展示系统的自恢复能力。5.2 电机噪声是怎么钻进ADC的以及我的三层防御现象是电机一启动压力读数就会跳声音频谱的低频段也会出现规律性的尖峰。这是典型的传导干扰。硬件层电机两端并联100nF电容吸收高频电源线上串一个共模电感继电器线圈加续流二极管光耦实现控制侧和功率侧的电气隔离。布线与接地层功率部分的走线尽量短粗和控制信号线分开走不要平行。ADC的模拟地单独走在电源入口处单点汇合。软件层这一层最容易被忽略。我的做法是在软件里做窗口屏蔽——电机的启动瞬间前100ms和停止瞬间后50ms标记为敏感时间段这期间采集到的压力数据不参与判断只记录不处理。听起来有点土但实际效果很好因为干扰确实集中在这两个时刻。另外声音检测也做了类似处理如果当前正在播放提示音就暂停哭声判别避免自己的声音触发自己。5.3 老化测试到底该测什么演示前我做了48小时连续老化测试重点看这几项内存是否泄漏。FreeRTOS任务如果用动态创建长时间运行可能因为栈溢出或者内存碎片导致异常。我用的方法是每个任务都设了uxTaskGetStackHighWaterMark监控把最低水位打印出来如果某个任务的余量小于20%就要加大栈或者优化代码。看门狗是否会误触发。48小时里如果出现非预期复位说明某个任务的执行时间在特定条件下变长了需要查。传感器的长期漂移。SHT30比较稳但HX711的零点会随温度变化漂移。所以要记录每天的零点值必要时做温度补偿或者在上电时重新校准零点。通信是否断连。WiFi模块长时间运行可能会因为路由器信号波动掉线我的做法是加一个连接状态检测掉线之后自动重连重连失败超过10次就重启模块。// 栈水位检查示例 UBaseType_t watermark uxTaskGetStackHighWaterMark(NULL); if (watermark 32) { log_warning(task stack nearly full: %d, watermark); }5.4 现场演示的应急预案这是血泪经验。答辩现场最怕的事情是设备不动了、屏幕黑了、网络连不上。我准备了三个预案。第一准备一个演示模式。这个模式下所有功能自动轮播不依赖你手动操作。因为答辩时间有限老师也不可能等你慢慢按按键。我用一个按键长按3秒进入演示模式每15秒自动切换一个功能展示全程不需要干预。第二准备一份本地数据截图或者短视频。如果现场设备真的出问题你可以直接播放提前录好的运行视频同时解释技术细节。这不是作弊工程上这叫降级方案本来就是系统设计的一部分。第三准备一块备用板。程序烧好的、测试通过的备用板成本不高。万一主板上某个元器件松了或者烧了直接换板继续演示不至于整个答辩崩掉。还有个小细节演示前一定要把蜂鸣器的音量调低或者用LED替代。答辩教室里如果突然响起刺耳的报警声会把气氛搞得很尴尬。6. 论文、图纸和答辩把工程活儿翻译成毕设语言6.1 论文框架怎么搭才不空单片机类毕设论文最常见的毛病是前半部分抄教材后半部分贴代码。要避免这个我的做法是把每一章都绑定到一个具体的决策上。绪论不要泛泛讲智能化是趋势直接讲你调研了哪些现有方案它们的不足是什么你的方案针对性地解决哪一点。方案论证这一章是重点。主控为什么选STM32不选51传感器为什么用SHT30不用DHT11通信为什么用WiFi不用蓝牙——每一条对比都要有表格、有数据、有结论。老师最爱看的就是这一章因为它能区分我抄的和我想过的。硬件设计原理图分模块画每个模块配一段说明。重点讲清楚电源、隔离、滤波这三处的设计理由。软件设计不要贴大段代码用流程图论文里可以用Visio画和表格说明任务划分、状态机转移、协议格式。关键算法比如FFT判据可以写伪代码或者核心几行代码。测试与分析这一章必须有数据。温湿度的误差范围、哭声识别的检出率和误报率、摇摆的频率实测值、连续运行时间。哪怕是自测数据只要方法说清楚就是加分项。结论写清楚做到了什么、有哪些不足、后续可以怎么改进。6.2 测试数据怎么补才不假老师一眼就能看出数据是编的。编的数据往往是温度误差±0.3℃这种整数而真实数据一定是带噪声的比如在25℃环境下连续测量20次最大偏差0.31℃标准差0.09℃。我的建议是老老实实测。温湿度可以用标准温度计对照声音可以用手机播放已知录音测试摇摆频率可以用手机慢动作视频数次数。这些测试不需要专业设备一个下午就能做完但得到的是一手数据答辩时你被追问也能答上来。做测试的时候注意记录测试条件环境温度、供电电压、距离、测试时长。这些信息写在论文里会显得很专业。6.3 答辩时最可能被问到的问题按我的经验高频问题有这几个你的哭声识别和市面上几十块钱的产品比优势在哪不要吹牛。诚实的回答是我的方案在实验室条件下检出率约88%、误报率低但受麦克风灵敏度和环境噪声限制无法和专业产品相比。我的价值在于实现了一个完整可解释的算法流程并且验证了可行性。这种回答老师能接受反而显得你清楚自己的边界。为什么用RTOS裸机不能做吗回答要点是时序冲突音频采集有硬实时要求UI刷新不紧急但也不能完全阻塞RTOS能保证高优先级任务的响应时间可预测。如果传感器坏了系统会怎样这是一个考察鲁棒性的问题。你要能说出I2C有CRC校验连续读取失败会标记传感器故障并在屏幕上显示同时该通道的数据不参与报警判断。这个东西的成本多少提前算好BOM表把每个元件的单价列出来最后给出总价。这个准备成本很低但会给老师留下考虑过工程落地的印象。6.4 这个项目后面还能往哪些方向延伸如果你做完基础版还有时间有几个方向是投入产出比较高的一是把本地判断升级成本地云端的二级结构本地做实时判断保证响应速度云端做长期数据记录和趋势分析。二是把摇摆的控制从固定曲线升级成基于体动反馈的自适应控制比如检测到婴儿躁动时自动加大摆幅安静后自动减小。三是加入语音提示但这需要额外的语音模块和更多的存储空间。需要提醒的是不要在毕设周期内追求功能数量。我见过太多人最后一个月疯狂加功能结果原有的功能都调不稳。把已有的八个功能做扎实把数据测准把论文写清楚这个成绩一定不会差。我个人在这个项目里最大的体会是单片机项目真正难的地方不在写代码而在于你怎么定义问题的边界。一开始我总想做得更多后来发现每增加一个功能就意味着多一个可能的故障点、多一组要测试的数据、多一个答辩时要解释的东西。做减法比做加法难但做出来的东西质量完全不同。如果你正在纠结要不要再加一个功能我的建议是先停下来把现有的功能连续跑通48小时再决定。