企业官网建设流程全解析

每年到毕设选题季，智能婴儿床这个题目总会被很多人盯上。原因很简单，市面上带声控摇晃、尿湿提醒、温湿度监测功能的智能婴儿床动辄两三千，看起来“很有技术含量”，但把外壳拆掉往里面看，核心就是一颗STM32单片机、一组传感器、一个舵机加一个WiFi模块。用STM32做毕设，不仅难度适中，而且从硬件到软件再到调试，每个环节都有东西可写，论文也撑得住。

这篇文章我就按我自己做完这套基于STM32的智能婴儿床系统的思路，把整个设计的完整实现过程拆开来讲：需求怎么定、芯片怎么选、传感器怎么接、逻辑怎么跑、远程报警怎么传、整机联调有哪些坑。无论是大四做毕业设计，还是低年级做课程设计、电子竞赛练手，这份笔记都能帮你省掉一大半自己踩坑的时间。

1. 需求拆解：智能婴儿床的“智能”到底落在哪

很多同学拿到这类题目，第一反应是“先把功能堆上去”：温湿度、哭声检测、尿湿检测、自动摇晃、蓝牙、WiFi、摄像头、App，能加的全加上。结果到了中期检查发现，每个功能都是半吊子，检测到了只会“在OLED上显示一下”，老师一问“检测到之后系统做了什么闭环反应”，人直接愣住。

1.1 核心痛点与功能映射

做设计之前，我先列了一张“家长真实痛点 vs 系统功能“的对照表。智能婴儿床本质上解决的就是这几件带娃过程中最折腾人的事：

• 宝宝哭了，需要人抱着摇。对应功能：声音检测 + 舵机驱动的自动摇晃安抚。
• 尿布湿了，宝宝不舒服会哭，拖久了还容易红屁股。对应功能：尿湿检测，触发本地声光提醒和远程推送。
• 踢被子了，体温受凉。对应功能：床内温湿度检测，温度过低或过高时报警。
• 家长不在房间，不知道宝宝状态。对应功能：ESP8266将状态上报到手机端，实现远程查看。

这套映射关系是整篇论文逻辑链条的起点，也是答辩时老师最认可的部分。你得让他看到你不是在“做一个遥控车”，而是在“解决一个真实问题”。

1.2 毕设的功能边界：不是功能越多越好

我的建议是，把系统控制在6个以内的大模块，并且每个模块必须形成闭环。什么叫闭环？就是“检测到异常 => 触发本地动作 => 上报/提醒 => 恢复或停止”，四个环节缺一个都不完整。

我见过太多人把毕设做成一个“多功能检测仪”——PM2.5也测、火焰也测、烟雾也测、人脸也识别，最后所有数据都堆在一个屏幕上一个串口里，这不叫系统，叫仪器。智能婴儿床要想拿到好成绩，重点不在传感器数量，而在“决策逻辑”和“闭环反馈”。

1.3 系统总体技术指标

在动手之前，我先把一些可量化的指标定下来，方便后期调试和论文里写测试报告：

有了这张表，后面每一步选型和调试都有据可依，论文里的“测试与结果分析”章节也就有东西写了。

2. 硬件选型：为什么是STM32F103C8T6，传感器怎么挑

2.1 主控芯片：STM32F103C8T6是毕设的“安全牌”

主控我选的是STM32F103C8T6，这颗芯片在本科生毕设里几乎是统治级的存在，理由非常实在：

• 价格低，几块钱到十几块钱一片，核心板也便宜，画错板子不心疼。
• 资料全网最多，遇到问题一搜就有答案，库函数版本和HAL库版本都有大量现成案例。
• 外设够用：3个USART、2个ADC、4个16位定时器、I2C、SPI，覆盖这个项目需要的全部功能。
• 能用STM32CubeMX图形化配置引脚和时钟，Keil MDK直接编译下载，开发效率比纯寄存器开发高太多。

有人会问，为什么不用51单片机？51做这种多传感器、多状态、带PID频率控制的系统，Flash和RAM都吃紧，代码写起来非常憋屈。也有人问为什么不用ESP32？ESP32强在WiFi和蓝牙，但它的定位偏向物联网模组，在“单片机课程设计”的评审语境下，用STM32更容易和课程知识对应上，导师也更容易给分。

2.2 传感器选型：能买到、够便宜、资料多

传感器选型我踩过一些弯路，最后定下来的方案是这样：

2.3 电路设计与供电分配：最容易翻车的一环

这个项目的供电设计非常关键，也是最容易被忽视的。我最初把舵机、ESP8266、单片机全部挂在一个AMS1117-3.3V稳压器上，结果只要舵机一转，单片机就重启。

整机供电分配建议如下：

• 外部电源：5V/2A的USB适配器，或者两节18650电池组。
• 5V直接给舵机供电，走单独一路，不经过稳压。
• 5V经过AMS1117-3.3V给STM32、DHT11、OLED供电。
• ESP8266-01S单独用一颗AMS1117-3.3V供电，峰值电流大，不能和单片机共用。
• 主电源输入端并联一个大容量电解电容（470µF以上），用来吸收舵机启动时的大电流冲击。

我当时还特意给每个传感器模块加了一个0.1µF的去耦电容，说实话板子上不一定看得出区别，但答辩老师问“为什么这里要加电容”的时候，你能答上来，这就是加分项。

3. 传感器数据采集与处理：从硬件信号到软件可用的数值

3.1 多通道ADC采样：声音传感器和尿湿检测的模拟量读取

LM393麦克风模块和自制尿湿电极电路，输出都是模拟电压信号，需要接入STM32的ADC引脚。我用的是ADC1的通道0和通道1：

• PA0：声音传感器模拟输出（连接LM393模块的AO引脚）
• PA1：尿湿检测比较器模拟输出（或直接接电极分压点）

我用STM32CubeMX配置ADC为“扫描模式 + 连续转换模式”，DMA搬运数据。为什么不直接用阻塞式读取？因为主循环里有很多任务要跑，如果每次读ADC都阻塞几十微秒，系统流畅度会受影响。DMA方式读ADC是毕设答辩时一个不错的亮点，你可以在论文里写“采用DMA方式采集，降低CPU占用率”。

采样数据处理部分，我用了“中值滤波 + 滑动平均”两级处理：

// 伪代码，示意数据处理逻辑 #define SAMPLE_NUM 10 uint16_t raw_buf[SAMPLE_NUM]; uint16_t get_median_adc(void) { // 1. 从DMA缓冲区拷贝原始数据 // 2. 对raw_buf排序 // 3. 返回中间值（或中间两个值的平均） // 4. 对连续3次中值结果再做滑动平均 }

为什么要用中值滤波而不是直接求平均？因为声音信号里会有尖峰脉冲，比如关门声、手机铃声，这些尖峰如果参与直接平均，会把阈值拉得很高，导致后面真正的哭声触发不了。中值滤波能很好地剔除这种孤立尖峰。

3.2 DHT11的时序与避坑细节

DHT11用单总线通信，一个引脚既做时钟又做数据，STM32要精确控制延时，特别是读时序时每一位的采样点位置。

核心读取过程大概是：主机拉低总线18ms以上发出启动信号 -> 释放总线 -> DHT11应答 -> 连续输出40位数据（8位湿度整数 + 8位湿度小数 + 8位温度整数 + 8位温度小数 + 8位校验和）。

用HAL库写的时候，有一点特别坑：STM32的GPIO速度如果配得太慢，微秒级延时误差会很大，导致数据位读错。我最终是这么处理的：

• 把DHT11数据引脚配置为开漏输出，外部加上拉电阻（4.7kΩ 到3.3V）。
• 切换输入/输出模式时，用寄存器操作而不是HAL库函数，减少函数调用开销。
• 所有延时候选方案最终统一用DWT->CYCCNT精确延时，而不是HAL_Delay。

另一个重要细节是：DHT11两次读取操作之间必须间隔1秒以上，否则传感器会不更新数据，返回的永远是上一次的值。这在主循环里要加一个时间戳判断。

if ((HAL_GetTick() - last_tick) >= 1000) { dht11_read_data(&temp, &humi); last_tick = HAL_GetTick(); }

3.3 尿湿检测自制电极：一个容易被忽略的“化学”问题

尿湿检测我一开始用的是裸铜电极，焊在洞洞板上直接放进小床垫，结果用了两天就发现铜箔被腐蚀发绿了，模拟输出电压漂移严重。原因是尿液里的盐分对铜有很强的腐蚀性，工作一段时间后电极表面状态变了，读取数值就不再可靠。

后来我把电极换成了两片不锈钢片，交叉排列成梳齿状，固定在床垫表层下方，间距控制在5mm左右。尿液浸湿床垫后，电极之间的阻抗会从几百千欧掉到几十千欧，配合一个LM393比较器电路，输出电压会明显跳变。

电路连接是：5V —— 10kΩ —— 电极A —— 电极B —— GND，电极A和电极B的连接点接到LM393的同相输入端，反相输入端接一个可调电位器用来设定触发阈值。无水时节点电压接近5V，有水时电压被拉低，比较器输出翻转，这个信号接到STM32的普通GPIO（配置为数字输入）即可。

如果你不想自己焊比较器电路，也可以直接用市场上的土壤湿度模块，探头面积大，检测灵敏，但答辩时老师可能会问“你怎么解决金属电极极化问题”，自己设计过电极的人，回答起来明显更有底气。

3.4 OLED显示与按键交互

显示模块用的是0.96寸OLED，SSD1306驱动芯片，I2C接口。STM32的硬件I2C在F103上存在一些兼容性问题，很多人用软件模拟I2C，稳定性更好。我这里直接用了硬件I2C，配好时钟和引脚后反而没出问题，但如果你遇到HAL_I2C卡死，别纠结，直接改成软件模拟I2C，一劳永逸。

OLED要显示中文，需要用取模软件（PCtoLCD2002）生成中文字模，取模方式选择“列行式、逆向、逐列式”，这样和OLED驱动库里显示函数的扫描方式一致，否则字会变成镜像或乱码。

按键我用了3个独立按键：菜单切换、加、减。按键消抖不用外部硬件，直接在定时器中断里每10ms扫描一次，连续3次电平一致才判定按下，效果非常稳。

4. 核心控制逻辑：状态机架构比一锅粥的if-else强在哪

4.1 为什么这个项目必须用状态机

如果不做状态机，整个主循环会变成这样：先采集传感器、然后判断要不要摇床、摇床时调用延时函数、延时期间OLED不刷新、按键也没响应、突然又来一个报警，整套流程卡死。

状态机的价值在于：把系统拆成几个明确的状态，每个状态下只做当前该做的事，状态之间通过明确的迁移条件跳转。这样代码可读性强、好调试，也给论文增加了“软件设计”的深度。

4.2 三个核心状态的定义与迁移

我的系统定义了三个状态：

• STATE_IDLE（待机监测）：系统正常运行时大部分时间处于这个状态，只做传感器采集、数据显示、阈值判断，不输出任何执行动作。
• STATE_SOOTHING（自动安抚）：检测到哭声信号后进入，舵机开始小角度往复运动，蜂鸣器播放柔和的“白噪音”音调，持续3~5分钟后自动回到待机状态。
• STATE_ALARM（报警状态）：哭声连续触发超过设定次数，或温湿度越限，或尿湿检测触发，系统会持续蜂鸣报警，并通过ESP8266向手机端推送报警信息。

状态迁移条件我整理成了一张表，写论文的时候也直接用这张表：

4.3 主循环的非阻塞写法

状态机要想跑得流畅，主循环里就不能有阻塞式延时。我的做法是用HAL_GetTick()做时间戳判断，替代HAL_Delay()。

// 主循环示意 while (1) { uint32_t tick = HAL_GetTick(); // 每20ms执行一次按键扫描 if (tick - last_key_tick >= 20) { key_scan(); last_key_tick = tick; } // 每100ms执行一次传感器读取和OLED刷新 if (tick - last_sensor_tick >= 100) { sensor_read_and_filter(); oled_refresh(); last_sensor_tick = tick; } // 每500ms执行一次状态机逻辑 if (tick - last_state_tick >= 500) { state_machine_run(); last_state_tick = tick; } // ESP8266数据发送 if (tick - last_upload_tick >= 5000) { esp8266_upload_status(); last_upload_tick = tick; } }

这样写的好处是：无论舵机在转还是蜂鸣器在响，OLED都能持续刷新，按键也始终有响应，整机不会有“卡死”的感觉。

4.4 舵机PWM控制：小角度往复才是安抚，不是猛摆

SG90舵机的控制信号是50Hz的PWM，高电平宽度0.5ms对应0度，1.5ms对应90度，2.5ms对应180度。STM32用定时器产生PWM，比如TIM2的CH1通道输出到PA0，配置PWM频率为50Hz，改变比较寄存器的值就能改变角度。

自动摇晃的逻辑不是大幅摆动，而是以中线±15度的小角度往复运动，周期约2秒一次。这个参数我实测下来比较合适，太大会让床体晃动过大，太小又起不到安抚作用。

void soothing_toggle(void) { // 每1秒切换一次方向 if (soothe_dir == 1) { set_servo_angle(SOOTHE_MID + 15); } else { set_servo_angle(SOOTHE_MID - 15); } soothe_dir = !soothe_dir; }

刚开始做的时候，我试图在舵机上做PID闭环控制，后来发现是过度设计——SG90这种模拟舵机本身有位置闭环，没必要再用MCU做一次，直接开环给PWM转角度就行。把PID留给论文里写“后续优化方向”就够了。

5. 本地交互与远程报警：OLED菜单和ESP8266数据上传

5.1 OLED菜单设计：一屏一件事，两层深度

屏幕虽然小，但也得讲究信息架构。我设计了4个页面：

• 主页：显示当前工作状态（待机/安抚/报警）、温度、湿度、尿湿状态。
• 设置页1：声音灵敏度阈值，通过加减按键调整。
• 设置页2：自动摇晃持续时间，默认3分钟。
• 信息页：显示WiFi连接状态、最近一次报警时间。

按键逻辑是：短按菜单键切换页面，长按进入设置模式，设置模式下短按加减键调整数值。

这里有一个小技巧：OLED刷新不要整屏全部清空再重画，否则会有闪烁感。用局部区域更新的方式，哪个数值变了就只刷新那一小块区域，视觉上会流畅很多。

5.2 ESP8266-01S的工作模式与通信流程

ESP8266-01S是串口WiFi模块，我用STM32的USART2与它通信，波特率115200，通过AT指令控制。下位机需要做的工作是：

1. 模块复位：发送AT+RST，等待重启完成。
2. 设置工作模式：AT+CWMODE=1（Station模式），连路由器。
3. 连接路由器：AT+CWJAP="ssid","password"，等待返回WIFI CONNECTED和OK。
4. 建立TCP连接：AT+CIPSTART="TCP","192.168.1.100",8080。
5. 发送数据：AT+CIPSEND=<len>，然后发送指定长度的数据内容。
6. 接收服务端下发指令：串口会出现+IPD开头的数据，解析出来可以做远程控制。

这里我要重点强调：ESP8266-01S的3.3V供电必须单独供给，它的峰值电流可以达到300mA以上。如果和STM32共用一颗AMS1117，WiFi发包瞬间电压跌落，轻则模块掉线，重则单片机复位重启。我自己就是在这个地方折腾了整整两天，最后把供电分开才彻底解决。

AT指令解析的代码，建议用定长数据包的思路：每次收到\r\n就认为一条AT响应结束，然后在缓冲区里查找OK或ERROR关键字。这样实现简单，稳定性也够。

// 伪代码：等待AT指令返回OK uint8_t at_send_cmd(char *cmd, uint16_t timeout_ms) { // 1. 清空接收缓冲区 // 2. 发送cmd // 3. 轮询等待，直到收到 "OK" 或超时 // 4. 返回 1 表示成功，0 表示失败 }

5.3 数据包格式与远程指令下发

上报数据我用的是JSON格式，一次传输大约50字节，内容清晰：

{"type":"report","temp":26.4,"humi":52,"cry":1,"wet":0,"state":"SOOTHING"}

解析端无论是用Python脚本，还是用网络调试助手，读起来都很直观。JSON的组装在STM32端用sprintf就能完成，不需要引入cJSON库，内容不需要动态嵌套结构。

远程指令下发的格式也类似：

{"type":"cmd","action":"stop_alarm"}

STM32收到后判断action关键字，执行停止报警、复位系统等操作。这个“远程控制”的能力在答辩演示时非常加分，老师能直观看到“双向通信”而不只是单向上报。

5.4 手机端监测方案：答辩演示最稳的组合

远程监测这块有三个方案可选，我给出的建议是：

做毕设有一个现实问题：答辩现场的WiFi环境不一定给力。所以我的做法是：系统优先连接手机热点，电脑也连这个热点，这样即使没有公网，也能在一个局域网内完成全部演示。

6. 整机联调：我踩过的坑和实测数据

6.1 舵机一动作，单片机就重启

这是我最开始遇到的第一个大问题。现象非常典型：OLED显示正常，蓝牙连接正常，一切看起来没问题，但只要舵机开始转动，屏幕熄灭，系统重启，然后进入死循环。

原因排查链路是这样的：

• 第一步，用万用表测舵机转动时3.3V的电压，发现电压跌落到2.1V左右。AMS1117输入端是5V，输出3.3V，电压是不可能跌到2.1V的，问题一定出在输入侧。
• 第二步，测5V电源轨，发现舵机启动瞬间5V被拉到3.8V。问题确认在电源输入侧。
• 第三步，看原理图，5V适配器直接接到了舵机、AMS1117、ESP8266三路。舵机的启动电流瞬间可以达到700mA以上，直接把5V电源轨砸出一个大坑。

解决办法：把舵机的电源线直接从主板供电端独立出来，在5V输入端并联一颗470µF电解电容 + 一颗0.1µF陶瓷电容，作为瞬态储能。ESP8266也用独立的AMS1117供电。改完之后，舵机怎么转，3.3V电压都稳稳的。

这个坑非常有价值，因为它能引出一大段论文里的“系统可靠性设计”内容，包括电源完整性、去耦电容的作用、大功率执行器与数字电路供电隔离等话题。

6.2 声音传感器阈值“白天乱响、晚上不响”

LM393麦克风模块上有一个蓝色的电位器，用来调节灵敏度。我一开始把电位器拧到中间位置，阈值固定，结果白天环境噪声大的时候一直误触发，晚上环境安静的时候又检测不到哭声。

解决思路是给系统加一个“环境基线校准”：开机后，系统连续采样2分钟环境噪声，计算出平均值作为基线；运行时用实时值减去基线值的差值来判断是否有突发声音。代码实现不复杂，但效果提升非常明显。

另外还有一个细节：LM393模块放在床体框架上的时候，要避开舵机附近的震动传导区域，不然摇晃的时候舵机振动会产生很大的声音信号，形成“一摇就响、一响就摇”的死循环。

6.3 DHT11湿度卡在99%不再变化

有段时间系统显示的湿度一直是99%，我还以为是传感器坏了，换了一块新的还是一样。后来发现，是DHT11离尿湿检测区域太近，吸水棉垫的水汽直接附着到了传感器的感湿元件上，导致内部湿度饱和。

这个问题要从两方面解决：

• 硬件上：把DHT11移到床垫外侧，加一个带透气孔的塑料外壳，避免传感器直接接触高湿环境。
• 软件上：增加判断逻辑，当湿度连续30分钟保持在85%以上时，直接判定“尿湿或环境湿度过高”，提醒用户检查，而不是依赖具体数值。

这里也顺便说明一下，毕设做的是演示级、学习级的原型系统，不能替代真正的医疗级监控设备。在论文的结尾安全说明里，我会明确写出“本系统仅作为教学演示用途，实际使用中家长仍需履行监护义务”，这个不是套话，是负责任的做法。

6.4 尿湿电极被腐蚀与信号漂移

前面提到的铜电极腐蚀问题让我后来换了不锈钢电极。这里还有一个关键参数要现场标定：电极安装在床垫的哪个位置、间距多少，会直接影响检测灵敏度。

我做的标定流程是：

1. 把电极安装在床垫样品上，接入比较器电路。
2. 记录干燥状态下的比较器输出电压（约4.8V）。
3. 用5mL清水倒在电极区域，记录电压变化（约0.4V）。
4. 用5mL生理盐水倒在电极区域，模拟尿液，记录电压（约0.1V）。
5. 根据电压变化设定阈值电位器的位置。

这套“标定实验”数据放到论文里非常充实，也是答辩时一个很自然的展示点。

6.5 远程报警延迟实测

完成整机联调后，我做了几组实际测试数据，拿来做论文的“系统测试”章节：

6.6 关于“演示翻车”的保命经验

最后分享几个现场演示的保命经验，都是我实际经历过的教训：

• 面包板改焊接板：面包板在调试阶段很方便，但搬动两次后很容易有接触不良的问题，现场一个引脚松动，整个系统就废了。去嘉立创打样一块PCB，几十块钱，省心太多。
• 所有插件用热熔胶固定：杜邦线、排针、传感器插头，全部点一下热熔胶，防止搬运过程和演示过程中松动。
• 备份一段完整的演示视频：提前在环境稳定的时候录一段完整的功能演示视频，拷到电脑里。就算现场设备出问题，也可以放视频，答辩不至于冷场。
• 提前到答辩教室测试网络：如果演示要用WiFi，务必提前去教室测一下信号，连不上就立即切手机热点，不要到现场再找网络。

做完整套系统后，我最大的体会是：毕设的重点不是“把每个传感器跑通”，而是“把一堆独立零件组装成一个有决策能力、有反馈闭环的完整系统”。从需求定义、硬件选型、电路设计、嵌入式软件、通信协议到系统测试，这一条线走下来，才是毕设真正的价值所在。智能婴儿床这个题目之所以值得做，就是因为它足够小、足够具体，但又能把嵌入式开发的主线全流程都覆盖到。