项目编号X504281| 主控 STM32F103C8T6 核心板 | 身份采集 ESP32-CAM OV2640 | 楼层执行 28BYJ-48 步进电机 | 本地显示 OLED12864I2C | 按键 蜂鸣器 LED 指示 | 通信 HTTP POST TCP Socket | 服务端 jeesite SpringBoot MySQL 虹软 SDK摘要本文介绍一套面向电梯场景的人脸门禁与楼层调度系统。硬件侧以 STM32F103C8T6 为核心板ESP32-CAM 摄像头模组负责在按下开门键后拍照并把 JPEG 直接 POST 到服务端28BYJ-48 步进电机用转动圈数模拟楼层高度OLED12864 就地显示当前楼层与运行状态蜂鸣器在识别不通过时发声。人脸比对由服务端调用虹软 SDK 完成放行结论经 TCP Socket 回传主控后驱动电机动作。服务端基于 jeesite 平台与 SpringBoot 框架构建以 MySQL 完成数据持久化网页端提供用户与人脸绑定、楼层管理、门禁设备登记、实时数据查询与进出记录查询。一、项目概述电梯门禁的核心问题不是「要不要拦人」而是「怎么把人和楼层对上」。刷卡方案里卡内只有编号卡片丢失后后台既不知道是谁在用也无法把卡与某一层楼稳定绑定。本项目改用人脸作为身份凭据并把人脸库放在服务端硬件侧只承担触发、采集与执行。本文所述系统以 STM32F103C8T6 为主控外接 ESP32-CAM 摄像头模组、OLED12864 显示屏、28BYJ-48 步进电机、按键、蜂鸣器与 LED 指示灯摄像头负责按快门、服务端负责人脸识别、主控负责楼层判定与开门放行服务端基于 jeesite 平台与 SpringBoot 框架构建并以 MySQL 持久化网页端负责用户与人脸绑定、楼层管理、电梯实时状态与使用记录查询把身份核验、楼层调度与运行记录整合进同一套可远程查看的闭环。系统在 2025 年 5 月 完成整机联调多次测试表明「按键—拍照—上传—识别—回传—运行」这条链路可以稳定往返。1.1 系统技术架构系统自上而下划分成应用层、服务层、网络层、控制层与感知执行层五个层次。图 1 系统总体架构图五层的关键分工是摄像头只负责按快门与上传主控只负责判定楼层与驱动电机人脸比对始终在服务端。这也意味着换一套人脸库不必重新烧录固件。1.2 系统功能结构按部署位置划分为硬件系统、软件系统与交付服务三列。图 2 系统功能结构图三列之间只有一条边界设备侧只做「触发 采集 执行」人脸比对、身份判定与记录留存全部放在服务端。二、硬件系统设计2.1 硬件系统原理框图整块板子的中心是 STM32F103C8T6 核心板模块左侧是开门按键与摄像头模组右侧是步进电机、显示屏、蜂鸣器与指示灯整机由 TYPE-C 取电口单口供电。图 3 硬件系统原理框图从框图可以看出本项目在硬件上的一个取舍身份采集这一路只连了两根线。ESP32-CAM 与主控之间仅接IO1(TX)与IO3(RX)分别落在PA10与PA9上也就是 USART1 的收发脚供电另走 5 V 与 GND。模组其余引脚在图上没有任何网络 —— 这说明主控并不经手图像数据JPEG 由模组自己经网络直接上传服务端。2.2 硬件原理图原理图用嘉立创 EDA 绘制同时提供 pdf、png、json 与 schdoc 四种格式。本文的接线描述以json源文件中的网络标号为准。图 4 硬件原理图提示解析原理图时建议直接读嘉立创 EDA 的json源文件。导出的 PDF 文字层只会包含已经连线的部分而源文件里能取出「引出但未连接」的悬空网络标号 —— 本项目正是靠这一点发现核心板右侧的PB5与3.3V属于预留脚。提取方式是从schematics[0].dataStr.shape这组字符串里用\^\^([\d.\-])~([\d.\-])\^\^(\S?)~取网络标号坐标用spiceSymbolName\([^\]*)\ 取元件型号。2.3 硬件实物实物装配以蓝色洞洞板作底板蓝色核心板压在板面中部28BYJ-48 步进电机经彩排线引出到板外OLED12864 挂在板面下缘摄像头插座与串口扩展口留在板边整机由一根 USB 线供电与下载。图 5 硬件实物总览OLED12864 上实测显示四行智能电梯门禁、楼层01 F、状态停止以及一行人脸识别失败。前两行说明屏幕上的汉字是提前取模固化的只能显示预先取好的内容最后一行说明识别未通过的提示会直接落在屏幕上不必等人去后台查记录。图 6 板载器件与接线特写2.4 引脚分配连接对象信号引脚说明步进电机 28BYJ-48A 相PA0四相依次落在 TIM2 的通道 1 上默认映射即可用步进电机 28BYJ-48B 相PA1同上通道 2步进电机 28BYJ-48C 相PA2同上通道 3步进电机 28BYJ-48D 相PA3同上通道 4电机 5V 与 GND 另行供电轻触按键 SW3输出PB1另一端经 R210 kΩ接地开关的另一组触点接 5 V蜂鸣器信号端PB0另一端接地由普通 GPIO 直接驱动ESP32-CAMIO1(TX) / IO3(RX)PA10 / PA9对应 USART1模组 1 脚接 5 V、2 脚接地OLED12864SCK / SDAPB6 / PB7IIC 屏上 SCK 即 SCL与硬件 I2C1 的默认分配完全一致OLED12864VCC / GND5V / GND模块 1 脚GND接地、2 脚VCC接 5 V核心板悬空网络PB5 / 3.3V—图纸在核心板右侧引出了 PB5 与 3.3V 两个网络标号但没有任何器件接上去属预留把这几根线排开来看落点并不随意· 步进电机四相PA0/PA1/PA2/PA3恰好是TIM2 的通道 1 至 4默认映射即可用· 显示屏SCK/SDA落在PB6/PB7正是硬件 I2C1 的默认分配· 摄像头两线落在PA9/PA10正是USART1 的收发脚·PB0给蜂鸣器、PB1给按键配R210 kΩ· 核心板右侧的PB5与3.3V悬空未接属预留三组外设各占一路片上外设彼此不抢资源。三、逐线核对原理图得到的四处判断把嘉立创 EDA 源文件里的网络标号提取出来、与 PDF 文字层逐条对照后有四处值得单独说明。3.1 步进电机的四相正好落在同一路定时器的四个通道上28BYJ-48 的 A、B、C、D 四相依次接 PA0、PA1、PA2、PA3。这四个脚恰好是 STM32F103 的 TIM2 通道 1 至通道 4默认映射即可用也就是说四相驱动脉冲可以由同一路定时器的四个通道直接产生既不必为每一步序再去找别的定时器也不需要靠软件延时来凑节拍。对步进电机这种要求四相严格按时序轮流的器件这样的落点是相当整齐的。3.2 显示屏的接线恰好与硬件 I2C1 的默认分配吻合OLED12864 的 SCK 接 PB6、SDA 接 PB7。在 IIC 屏上 SCK 就是时钟线 SCL而 STM32F103 的硬件 I2C1 默认功能分配正是 SCL PB6、SDA PB7两者完全一致。这块屏因此具备直接调用片上 I2C1 外设的条件不必再用通用 IO 去模拟时序。3.3 摄像头只占两线串口图像不经主控搬运ESP32-CAM 与主控之间只连了 IO1(TX) 与 IO3(RX) 两根线分别接 PA10 与 PA9 —— 正是 USART1 的收发脚供电另走 5 V 与 GND。模组其余引脚在图上没有任何网络。换句话说主控这一侧并不经手图像数据它只负责触发拍照与接收识别结果JPEG 由模组自己经网络直接上传服务端。这条链路上主控不是数据通道只是事件触发器。3.4 核心板引出的 PB5 与 3.3V 属于预留图纸在核心板右侧引出了 PB5 与 3.3V 两个网络标号但从头到尾没有任何元件接上去。相比之下其余各脚都各就各位PA9 / PA10 给了摄像头、PA0 ~ PA3 给了步进电机四相、PB0 给了蜂鸣器、PB1 给了按键、PB6 / PB7 给了显示屏。读原理图时把「引出来但没接东西」的脚单独记一笔能避免在写接线表时凭位号顺序想当然。以上四条并非对设计的质疑而是对既有连线的如实描述 —— 本文只记录原理图上真实存在的连接不对作者的意图作推测。四、通信链路与数据交互4.1 通信参数链路协议 / 方式说明无线承载Wi-Fi 2.4 GHzSTA 模式默认热点名 8266wifi、密码 123456789说明文件里特别注明需使用电脑开热点图像上传HTTP POSTREST 方式相机端把拍到的 JPEG 直接 POST 到服务端的上传接口不经过主控转发指令通道TCP Socket服务端与硬件之间以 TCP Socket 周期性同步状态、下发指令服务端地址192.168.137.250上传接口端口 8889Socket 端口 19214两项在同一台内网主机上相机模组自身地址192.168.137.210模组连上热点后自己拿到一个内网地址串口会打印 Camera Ready 与这个地址人脸识别位置服务端调用人脸识别 SDK方案里注明通过虹软 SDK 方式实现人脸检测与人脸识别识别不在主控上做调试观测模组串口打印上电后依次打印 WiFi connected、Camera Ready并输出「CZHBH01_900000#」与「CZHBH01_901000#」这类状态行为遵守平台规范本文涉及的服务地址一律省略协议前缀实际配置以完整地址为准。图片链路与指令链路分开是本项目在通信设计上最实用的一处安排。一张 JPEG 少则几十 KB如果让它和放行指令挤在同一条通道上识别结果就要排在图片后面慢慢等而现在图片走 HTTP POST 直奔服务端指令走 Socket 独立往返两边互不阻塞。4.2 数据交互时序以「刷一次脸乘梯」为例整个过程分成十二步按键触发、发出拍照指令、图像以 HTTP POST 上传、服务端建立识别记录、调用识别引擎比对、结果写入记录、结论经 TCP Socket 回传、主控解析、通过则驱动电机模拟运行并刷新屏幕、不通过则蜂鸣器鸣响并提示。图 7 系统数据交互时序图这张图里有两处值得展开。第一处是「主控全程不搬运图像数据」摄像头模组与主控之间只有两根串口线JPEG 从模组直接进网络主控只是事件的触发者。第二处是「比对结果不落在硬件上」住户的人脸照片存在服务端硬件侧既没有特征库也没有比对逻辑。五、软件系统与界面功能5.1 界面字段界面分组字段与说明用户管理姓名 / 电话 / 楼层 / 人员状态 / 照片路径 / 更新时间 — 按姓名与电话检索右上角另有「新增」「照片路径」一栏不是路径文本而是以内嵌缩略图直接回显已绑定的人脸照片新增用户姓名 / 电话 / 楼层 / 图片上传 — 页头写明「手机号码将作为登录的账户信息」楼层为下拉选择默认第 1 楼图片上传区提示可拖拽或点击选择最多上传 1 张门禁设备管理设备编号 / 设备名称 / online / 更新时间 — 登记每一台梯控设备的编号、名称与在线状态查询条件为设备编号与设备名称实时数据查询当前楼层 / 目标楼层 / 运行状态 — 三张状态卡同步刷新下方「实时图像」按时间列出最近几次识别画面进出记录查询姓名 / 电话 / 楼层 / 类型 / 进出时间 / 照片路径 — 「类型」一栏取「外出」或「回家」每一次放行都单独留痕查询条件为姓名与电话把这五组与硬件对照可以看清数据的来路「当前楼层 / 目标楼层 / 运行状态」直接取自主控上报的状态与 OLED 上显示的是同一份数据「进出记录」里的类型外出 / 回家则由服务端按比对结果写入。5.2 登录页与住户登记登录页是整套系统的入口背景是一张电梯厅实景正中的白色卡片上给出「登录账号」「登录密码」两个输入框与一个「登录」按钮。图 8 登录页与新增用户页新增用户页的页头写着基本信息【手机号码将作为登录的账户信息】也就是说手机号同时承担账号与联系方式两个角色。字段依次为姓名、电话、楼层下拉默认第 1 楼与图片上传最多 1 张。这里有一处值得留意人脸是以照片形式绑定的而不是把特征值写进硬件 —— 照片存在服务端比对也在服务端做。5.3 用户管理与门禁设备管理图 9 用户管理页与门禁设备管理页用户管理页实测注册了 4 条记录王五3 层、张三5 层、林超4 层与雷天昊2 层人员状态一栏均为离家。「照片路径」一栏显示的不是一串路径文本而是一张缩略图 —— 说明人脸是以图片形式存放在服务端页面渲染时把图片回显出来。门禁设备管理页实测只有 1 台设备编号ZDBH01、设备名称梯控、online 状态在线、更新时间2025-05-04 13:12:54。页面提供设备编号与设备名称两个查询条件也就是说加装第二台梯控设备时后台不需要改代码登记一条即可。5.4 实时数据查询图 10 实时数据查询页实测截取的一帧为更新时间2025-05-04 13:15:00、设备在线、当前楼层1楼、目标楼层--- 楼、运行状态停止。这帧数据里有两点值得注意· 「目标楼层」显示三个短横线而不是数字说明当下并没有待执行的呼叫电梯处于驻停状态· 「运行状态 停止」与「当前楼层 1楼」同时出现与屏幕上显示的楼层01 F / 状态停止完全对应 —— 两者是同一份状态下方「实时图像」区横向排开五张识别画面作用是让人一眼看到最近几次有人经过摄像头时的画面配合进出记录页可以核对某一条记录对应的影像。5.5 进出记录查询图 11 进出记录查询页实测该查询共 31 条记录每页显示 20 条共 2 页。页面前六条依次是王五外出 13:06、王五回家 13:06、张三外出 13:04、雷天昊回家 12:59、雷天昊外出 10:51、雷天昊回家 10:50。从这六条能看出「类型」一栏的取值是成对的同一个人先「外出」后「回家」每次放行单独落一条记录而不是把一次出行合并成一行。这种记法带来的好处是时间线完整代价是表格里会有大量同名行所以查询条件才把姓名与电话并列。说明本项目界面截图含真实手机号与人脸照片已在交付前统一作不可逆遮蔽马赛克 高斯模糊。遮蔽后经高频细节能量自校验各遮蔽区域降至原值的 0.3% 以下。六、固件烧录与调试硬件侧程序用 Keil 5 开发烧录走串口下载工具完成。图 12 串口烧录工具的烧录记录实测这一条烧录记录的内容是端口 COM33, 波特率 115200 芯片 ID: 0x000412 STM32F103xx Low-density 芯片 Flash 容量为 32KB 开始擦除全部片内 Flash ... 成功 开始从 08000000 开始编程 ... 成功 成功从 08000000 开始运行 耗时 0.128 秒把这条记录与实物照放在一起看可以说清楚一件事板子上的程序是通过串口写入并已经跑起来的。七、系统视频展示演示视频完整记录了系统从登录、录入人脸、绑定楼层到按下开门键触发拍照、服务端识别、电机运行至目标楼层的全过程时长约 5 分 47 秒。图 13 演示视频封面视频里可以重点看三处一是按下开门键到屏幕出现识别结果之间的停顿这段时间正是图像上传与人脸比对在服务端跑二是识别通过后步进电机的转动圈数与楼层差是对应的三是识别不通过时的动作 —— 蜂鸣器鸣响、屏幕提示门并不打开。八、交付内容交付项形式硬件实物已装配并完成联调的整机扩展板 杜邦线程序源码STM32F103C8T6 固件工程与 Java 服务端 网页端工程硬件原理图嘉立创 EDA 源文件json / schdoc及导出的图像与文档演示视频系统完整运行的演示录像约 5 分 47 秒技术支持远程协助环境搭建、程序调试与小规模修改答疑如需完整交付清单可在站内私信说明项目编号X504281与用途学习 / 二次开发 / 课程设计会按用途给出对应的资料组织方式。