1. 项目概述一门期末大作业的“面试官视角”这个故事得从2024年那阵子说起。当时我刷到一个嵌入式应届生的作品集里面放着一个期末大作业——家用智能晾衣杆而这件作品堂而皇之地躺在他面试蚂蚁金服的PPT里。很多人第一反应是“这东西也敢拿出来面大厂”但仔细看下去你会发现这个作品其实把嵌入式常见的传感器采集、电机驱动、无线通信、小程序/云端联动全串起来了几乎覆盖了嵌入式岗位面试里“项目问答”环节80%的高频考点。这个项目解决的是日常晾衣场景里的一个真实痛点家里没人突然下雨了晾在外面的衣服怎么办传统晾衣杆要么靠人手动收要么买几千块的电动晾衣架但对学生党或租房党来说自己动手做一个几十块钱成本的智能版本既能练手又能压在面试桌上讲出花来性价比拉满。对正在做嵌入式期末作业、毕业设计或者准备嵌入式/物联网方向面试的人来说这个项目特别值得参考。它不挑平台STM32、STC、ESP32都能跑难度适中从GPIO到中断到RTOS再到云平台接入层层递进而且每一层都可以在面试时做深度追问。我写这篇文章的初衷不是让你抄一份作业交差而是想把这个项目拆开揉碎讲讲它背后的设计逻辑、调试过程以及我从面试官角度看到的“亮点与雷区”。如果你正在为期末项目发愁或者简历里缺一个能打的物联网作品这篇内容应该能给你不少启发。2. 需求拆解与系统方案选型别急着买元器件2.1 需求清单先想清楚“自动”到底自动在哪做嵌入式项目最忌讳拿到题目就开干先把需求梳理清楚。家用智能晾衣杆的核心需求不用整得太花哨三条主线就够了自动收晾检测到下雨雨滴传感器就自动把晾衣杆收回检测到阳光充足光照传感器就自动伸出去晒。远程可控人在公司或地铁上打开手机小程序能看到当前天气状态和晾衣杆位置并能手动控制伸出/收回。安全保护与状态反馈电机运转要有极限停止逻辑不能把绳子拉断了还在转晾衣杆位置和传感器状态需要实时上报。我当时做的时候额外加了一个“手动优先”的逻辑只要人在家就能通过按键直接操作不受自动逻辑干扰。这个设计加分很大面试官一听就会觉得你考虑过真实使用场景——纯自动机器在家里是会被骂的手动接管永远是刚需。2.2 主控选型为什么我最后选了ESP32而不是STM32很多学校的嵌入式课程还在用STM32F103但如果你把“智能晾衣杆”当成一个物联网项目来做我建议优先考虑ESP32理由很实际ESP32自带Wi-Fi和蓝牙省掉外挂ESP8266模块的接线和调试成本。STM32要连Wi-Fi要么串口接ESP8266要么接ESP-01S多一层通信调试就多一批坑。ESP32的ADC精度和输入电压范围对光电传感器、雨滴传感器的适配更友好不需要额外做电平转换。STM32F103的ADC是3.3V参考如果传感器模块输出5V电平还要分压。ESP32支持Arduino框架和ESP-IDF两种开发方式期末时间紧用Arduino能快速出效果想卷一点上ESP-IDF还能讲FreeRTOS任务调度。当然如果你学校指定必须用STM32这个项目的逻辑也能完整复现只是Wi-Fi部分换成“STM32 ESP8266串口透传”代码量会多出一截调试串口波特率不匹配、数据乱码这类问题也会更耗时。我在下面的实现方案里会同时给两条路线的关键差异点。2.3 电机与结构方案减速电机、步进电机还是舵机晾衣杆的伸缩机构看起来简单实际上电机的选择直接决定项目的成败。我见过有同学用普通直流电机直接驱动滑轮结果电机扭矩不够晾衣杆纹丝不动也有人用舵机改但舵机角度有限没法实现长距离伸缩。最终我采用的是双向减速直流电机 行程开关 限位挡块的方案。选减速电机的原因是它自带齿轮箱扭矩够大能把转速降下来控制精度足够用于晾衣杆这种慢速直线运动。行程开关装在轨道两端钩子碰到就断电防止电机堵转过流。更讲究一点的做法是用步进电机做开环位置控制靠脉冲数精确知道晾衣杆位置但步进电机的驱动A4988或TB6600会额外增加成本和控制复杂度而且步进电机在低速大扭矩时容易发热家庭场景没必要这么较真。2.4 传感器选型便宜大碗的三件套雨滴传感器市面上最常见的LM393雨滴模块几块钱一块板上有一个十字形的感应区域水滴落在上面会导致两个电极间电阻变化输出模拟量和数字量两路信号。我用的是模拟量输出通过ADC读取电压值这样可以判断小雨、中雨、大雨而不是简单地触发一个“下雨/不下雨”的开关量。光照传感器用的光敏电阻模块也是LM393比较器输出输出模拟电压随光强变化。放在晾衣杆支架顶部朝上安装注意不要被电机外壳或晾衣杆本体遮挡。温湿度传感器这个是我自选的用了DHT11算是给项目增加一个“天气看板”的功能数据能上报到小程序里。DHT11精度一般但胜在便宜且驱动简单网上例程一抓一大把。想追求精度可以用DHT22也就贵个十块钱。2.5 通信方案MQTT是物联网的门票物联网项目的核心在“网”。ESP32采集到传感器数据、电机状态之后必须上传到云端手机端才能实时查看和控制。我选的是MQTT协议理由很简单它是物联网领域的事实标准协议轻量、基于发布/订阅模式对嵌入式设备的内存占用极低而且阿里云、腾讯云、百度云物联网平台全部原生支持。云平台我用的阿里云物联网平台因为学生有免费额度而且文档是全中文的对新手友好。设备端通过MQTT连接阿里云上报传感器数据主题/sys/xxx/thing/event/property/post接收云端下发的控制指令主题/sys/xxx/thing/service/property/set。小程序端则通过阿里云的HTTP API或AMQP服务端订阅来获取设备数据。这里有个关键认知**MQTT不是HTTP那种请求-响应的模式而是一种类似“订阅报纸”的模式。**设备订阅了“控制指令”这个主题云端一发消息设备就能收到设备把状态发布到“状态上报”主题云端所有订阅了这个主题的客户端比如你的手机小程序都能看到。理解了这个模型后面写代码基本不会跑偏。3. 硬件搭建与电路设计实操3.1 电路图核心节点整个系统的接线并不复杂核心节点如下雨滴传感器AOUT→ ESP32 GPIO34ADC通道光敏传感器AOUT→ ESP32 GPIO35ADC通道DHT11DATA→ ESP32 GPIO4继电器模块IN1→ ESP32 GPIO25继电器输出端接减速电机的正负极行程开关1收回限位→ GPIO26上拉输入行程开关2伸出限位→ GPIO27上拉输入按键手动收回→ GPIO14上拉输入按键手动伸出→ GPIO12上拉输入电源方面ESP32开发板用USB 5V供电电机和继电器用外部5V/2A电源供电注意继电器模块的信号输入端和电机电源之间要做好隔离。如果你用STM32ESP8266的方案就多出来一组串口连接STM32的USART1_TX/RX接ESP8266的RXD/TXD共地必须接好。3.2 继电器控制电机的反向旋转技巧直流减速电机要正转和反转普通的单路继电器做不到必须用双路继电器模块或者一个双刀双掷继电器来控制电机的H桥接法。我用的是一块2路继电器模块继电器1控制电机的VCC端继电器2控制电机的GND端当继电器1吸合、继电器2断开时电流从VCC流向GND电机正转反向操作则电机反转。两个继电器同时吸合或同时断开电机就停止。代码里要加一个严格的“互斥保护”在任何时刻都禁止两个继电器同时吸合否则相当于电源短路轻则烧保险丝重则起火。这是整个项目里最大的安全隐患我第一次调试时差点烧了电机驱动模块后来在代码里强制加了状态互斥判断并且硬件上串联了一个1A自恢复保险丝双保险才敢放心跑。3.3 行程开关的接法与去抖行程开关本身就是一个机械触点电机运行时的振动会导致触点抖动如果直接用GPIO中断去检测容易产生误触发。我采用“定时轮询 软件去抖”的方式每20ms读取一次行程开关状态连续读到3次相同的电平才认为状态稳定。独立按键也做了同样的去抖处理用的是经典的“延时10ms再读一次”方法。这个细节很小但面试官很喜欢在项目问答里追着问“你怎么消抖”两种方式硬件RC滤波和软件延时去抖你都答得上来项目可信度会高很多。3.4 供电拓扑与布线避坑做这类项目布线顺序比你想的重要。我一开始把所有器件都挂在ESP32的3V3引脚上结果DHT11数据跳动剧烈雨滴传感器读数也忽高忽低后来才发现是供电不足导致传感器工作不稳定。ESP32开发板的AMS1117稳压器本来就只能输出几百毫安带不动一堆传感器。正确的供电拓扑是ESP32开发板单独用USB 5V供电雨滴传感器、光敏模块、DHT11统一接在3V3排针上这几个传感器电流都很小ESP32能带得动继电器模块的JD-VCC引脚接外部5V电源VCC引脚接ESP32的5V用于给继电器线圈供电电机单独用5V/2A电源适配器供电不经过开发板地线必须所有模块共地具体做法是把ESP32的GND、外部5V电源的负极、电机驱动模块的GND全部接到一起否则电平基准不一致通信和采样全会飘。4. 软件设计从裸机逻辑到任务调度4.1 主状态机这个项目的灵魂我不建议把控制逻辑写成一大坨顺序执行的if-else因为晾衣杆的状态切换太频繁顺序逻辑容易漏状态。我用了一个简单的主状态机五个状态足够覆盖所有场景状态A晾衣杆缩回收回限位触发状态B晾衣杆伸出伸出限位触发状态C正在收回中电机反转状态D正在伸出中电机正转状态E停止初始状态或手动停止任何外部事件下雨、光照充足、远程指令都只是触发状态迁移的条件真正决定电机要不要转只看当前状态和迁移目标的组合。这种设计的好处是逻辑清晰不容易出现“电机卡在两个状态之间一直转”的死循环情况。4.2 控制逻辑核心代码ESP32 Arduino框架核心逻辑可以这样组织关键部分贴出来其余初始化代码省略typedef enum { STATE_RETRACTED, // 已收回 STATE_EXTENDED, // 已伸出 STATE_RETRACTING, // 收回中 STATE_EXTENDING, // 伸出中 STATE_STOPPED // 停止 } ClothesRackState; ClothesRackState currentState STATE_STOPPED; void rackControlLoop() { int rainValue analogRead(RAIN_SENSOR_PIN); int lightValue analogRead(LIGHT_SENSOR_PIN); bool isRaining (rainValue RAIN_THRESHOLD); bool isSunny (lightValue LIGHT_THRESHOLD); switch (currentState) { case STATE_RETRACTED: // 收回状态下如果雨停且光照充足且没有手动收回指令才伸出 if (!isRaining isSunny !manualRetractRequest) { motorForward(); // 正转伸出 currentState STATE_EXTENDING; } break; case STATE_EXTENDED: // 伸出状态下如果下雨、光照不足或手动收回就收回 if (isRaining || !isSunny || manualRetractRequest) { motorReverse(); // 反转收回 currentState STATE_RETRACTING; } break; case STATE_EXTENDING: if (digitalRead(LIMIT_EXTEND_PIN) LOW) { motorStop(); // 行程开关触发停止 currentState STATE_EXTENDED; } break; case STATE_RETRACTING: if (digitalRead(LIMIT_RETRACT_PIN) LOW) { motorStop(); currentState STATE_RETRACTED; } break; case STATE_STOPPED: // 手动停止后的恢复逻辑根据当前环境重新判断 if (manualRetractRequest) { motorReverse(); currentState STATE_RETRACTING; manualRetractRequest false; } else if (manualExtendRequest) { motorForward(); currentState STATE_EXTENDING; manualExtendRequest false; } break; } }注意传感器阈值不能写死我这里是把“雨滴传感器ADC值小于阈值”判定为下雨。不同环境下传感器的基值差异很大因此我在程序初始化时做了一个20秒的自校准记录上电后前20秒的传感器平均值作为基准值阈值设为基准值的60%雨滴传感器和基准值的130%光照传感器这样在不同天气、不同光照环境下运行误判率会低很多。4.3 传感器阈值校准为什么固定阈值不靠谱雨滴传感器有个很坑的特性没有水滴时AO引脚输出电压接近3.3VADC读数大概在3800-4095之间但只要沾了一点点水汽读数会瞬间掉到2000以下。如果阈值设高了可能晚上露水重一点就误判成下雨设低了小雨淋了半天才触发衣服早湿了。我的做法是“上下阈值滞回”判定下雨的阈值ADC 1500 持续2秒判定雨停的阈值ADC 2200 持续10秒这里故意让“雨停”比“下雨”更难触发中间留了700的滞回区间避免雨滴传感器表面的水分在蒸发过程中读数不停抖动导致电机频繁启停。类似的滞回逻辑也用在了光照传感器上。这个滞回思想是自动控制里非常经典的做法面试时主动讲出来会让面试官觉得你不是简单抄代码而是理解背后的工程考量。4.4 联网模块阿里云物联网平台的接入要点如果你用ESP32接入阿里云的流程是在阿里云物联网平台创建产品“smart_clothes_rack”选择自定义品类节点类型选“设备”连网方式选“Wi-Fi”。添加物理模型功能定义定义“RainStatus”整数类型0-1、 “RackPosition”整数类型0-100、“MotorState”枚举类型0停止/1伸出/2收回等属性。注册设备拿到三元组ProductKey、DeviceName、DeviceSecret。ESP32侧使用pubsubclient库连接MQTT broker地址格式是“${ProductKey}.iot-as-mqtt.${RegionId}.aliyuncs.com”端口1883。连接参数里ClientId格式固定为“${DeviceName}|securemode3,signmethodhmacsha1,timestampxxx”username是“${DeviceName}${ProductKey}”password用HmacSHA1算法对“clientId${ClientId}deviceName${DeviceName}productKey${ProductKey}timestamp${timestamp}”做签名。这套流程在阿里云官方文档里有详细说明但很多同学卡在密码签名这一步。我建议直接用阿里云官方提供的“设备端SDK”不要自己手写HmacSHA1签名省时省力。用MQTT.fx工具先在电脑上模拟设备接入确认云端通了你再烧到ESP32里排查起来会顺畅很多。4.5 小程序端不是必须自研但动手做会加分我当时做了一个微信小程序来显示状态和控制核心就两个页面设备状态页显示温湿度、光照强度、降雨状态、晾衣杆位置通过WebSocket或HTTP定时轮询从自己的服务器或者直接用阿里云提供的API拿数据。控制页两个大按钮“收回”和“伸出”点击后调用云端API下发指令到设备。小程序的技术栈不复杂就是微信官方的WXMLJS难点在于域名证书和HTTPS要求。为了快速演示可以直接在微信开发者工具里勾选“不校验合法域名”然后调用阿里云HTTP API。但这只适合开发调试上架需要正式域名。如果你不想做小程序改成用“阿里云天猫精灵”或“MQTT客户端App”直接控制也能达到效果。不过从小程序动手做一个完整闭环对于面试展示来说效果会好得多——你能讲的东西从嵌入式扩展到了前端和云端。5. 调试实录我踩过的那些坑5.1 现象一电机不转但继电器“哒哒”响排查步骤用万用表测继电器输出端的COM和NO口电压确认是否有5V输出。如果没有说明继电器触点没接通或模块供电异常。测继电器模块的JD-VCC和GND之间是否有5V。很多继电器模块上面有个跳帽出厂时默认把VCC和JD-VCC短接如果你给JD-VCC单独接外部电源就必须拔掉这个跳帽否则电源会打架。确认电机本身是好的是。直接把5V电源接电机两极能转就说明电机没问题。最后我发现是跳帽没拔外部电源和开发板电源短接电机端电压被拉低到2V左右根本带不动。拔掉跳帽后一切正常。5.2 现象二雨滴传感器过于灵敏对着它哈气就触发雨滴传感器的感应面是裸露的铜箔走线不仅对水滴敏感对空气中的水汽、甚至人体靠近时的电场干扰都很敏感。我一开始把传感器放在晾衣杆支架侧面结果每次有人从旁边走过读数就剧烈跳动。解决办法把传感器抬高正面朝上安装让雨水能直接滴落而不是靠气流带上去。用热熔胶把传感器背面的焊点和排针封起来防止受潮短路。在代码里加入“持续时间确认”连续2秒都满足“ADC 1500”才判定下雨。这个延时过滤非常有效。5.3 现象三Wi-Fi偶尔掉线重连逻辑必须自愈ESP32的Wi-Fi连接并不是永久的家里路由器偶尔重启、信号波动设备就会掉线。掉线后如果代码里没有重连逻辑整个远程控制就瘫痪了。我在loop()函数里加了一个心跳检测每5秒检查一次Wi-Fi连接状态如果断开了尝试重连最多尝试3次。MQTT连接也是一样的逻辑掉线后先重连Wi-Fi再重连MQTT。MQTT重连时注意需要重新订阅主题否则收不到远程指令。这个自愈逻辑让我在面试时意外加分了因为很多同学的能远程控制的设备演示时一旦网络波动就当场翻车。做嵌入式产品自恢复能力往往是面试官考察工程素养的关键点。5.4 现象四电机堵转后发热严重必须加过流保护有几次调试行程开关没装到位晾衣杆已经顶到边界了电机还在转。减速电机的堵转电流可以达到正常工作电流的3-5倍持续十几秒电机外壳就会烫手。我在硬件上加了两个保护电路串联1A自恢复保险丝电流超过阈值自动断开冷却后自动恢复。代码里加入了“最长时间保护”电机持续运转超过15秒不管行程开关有没有触发都强制停止并上报“运行超时”警告状态。6. 常见问题速查表现象可能原因排查/解决办法雨滴传感器读数飘供电不稳接3V3而不是5V或者给传感器单独加强滤波电容继电器吸合但电机不转跳帽未拔导致电源短接断开VCC与JD-VCC的短接跳帽外部供电直接接JD-VCC电机转向反了继电器输出线接反交换电机两根线的位置即可DHT11读数恒为0数据线没接对或漏上拉DHT11的DATA线需要4.7K-10K上拉电阻部分模块内置裸传感器需外接手机控制无响应MQTT未重连开启Wi-Fi/MQTT掉线自动重连并重新订阅所有主题收衣晾衣逻辑反复横跳阈值紧贴着环境噪声加入滞回区间雨通阈值1500雨停阈值2200晾衣杆收回超时行程开关触点氧化用万用表通断档测行程开关确认按压有反应必要时换微动开关编译报内存不足ESP32的Flash分区太小确认分区表选的是“Huge APP”而非默认的“No OTA”大固件需要更大的APP分区7. 写在最后从期末作业到面试谈资回到开头那个问题为什么带着“家用智能晾衣杆”这个作品也敢去面大厂我现在再回头看这个作品它最大的价值不在于“晾衣杆”本身有多高级而在于它体现了一个嵌入式开发者必须具备的系统思维——从物理世界采集信号到数据处理和状态判断到执行机构控制再到云端通信和应用层交互这条完整的链路你都亲手打通了并且你踩过坑、解决过问题能讲清楚每一个取舍背后的原因。用到这个项目里学到的东西我后来在不少实际工作中都反复用到状态机的设计模式是在任何嵌入式系统里都能复用的MQTT的发布/订阅模型几乎成了我做任何物联网设备接入的默认选择而传感器阈值滞回的理念更是让我在后来的工业项目中少走了很多弯路。最后再分享一个小技巧如果你想把这类作品放进面试简历不要只写“做了一个智能晾衣杆”而是写成“基于ESP32的物联网智能晾衣杆系统通过雨滴/光照传感器实现自动收展控制采用状态机模型管理执行逻辑经MQTT接入阿里云平台开发微信小程序实现远程状态监控与指令下发”。这样一句话把技术栈、架构、功能全部交代清楚面试官瞄一眼就能抓到重点自然也更有兴趣深挖你的设计思路。