项目编号 X504201 | 主控 STM32F103C8T6 核心板 | 视觉采集 ESP32-CAM + OV2640 | 到位检测 四路红外感应模块 | 闸机执行 SG90 舵机 | 本地显示 OLED12864（I2C） | 通信 HTTP POST + TCP Socket | 车牌识别 服务端调用百度在线车牌识别接口 | 服务端 jeesite + SpringBoot + MySQL
摘要：本文介绍一套以服务端车牌识别做决策的车位引导系统。硬件侧以 STM32F103C8T6 为核心板，三路红外感应模块分别盯着车位 1 / 2 / 3，另有一路负责出入感应；车辆到达时 ESP32-CAM 抓拍号牌，JPEG 由模组自己以 HTTP POST 直接上传服务端，图像不经过主控；服务端调用百度在线车牌识别接口返回号牌字符串，主控把识别结论与车位占用状态合并，驱动 SG90 舵机控制闸机放行，OLED12864 就地显示车位总数、剩余车位与收费单价。服务端基于 jeesite 平台与 SpringBoot 框架构建，以 MySQL 完成数据持久化，网页端提供用户管理、车场闸机管理、系统配置、实时数据展示与进出记录查询。
一、项目概述
车位引导的难点不在「数出还剩几个位」，而在「把车、车位与计费对上」。人工发卡只记入口一笔，场内哪些位空着、放行谁说了算、停车费怎么算，往往各管一段。本项目把三件事分到三个位置：红外感应负责「车什么时候到、停在哪个位」，服务端的车牌识别负责「认出这是哪辆车」，主控只负责「汇总状态、驱动闸机与就地显示」。
本文所述系统以 STM32F103C8T6 为主控，四路红外感应模块分别检测三个车位与车辆出入场，红绿 LED 指示车位占用、SG90 舵机做入场方向引导、OLED12864 显示车位概况、蜂鸣器在车位已满时提示，ESP32-CAM 采集现场图像；车牌识别由服务端调用百度在线车牌识别接口完成，服务端基于 jeesite 平台与 SpringBoot 框架构建并以 MySQL 持久化，网页端负责闸机与用户管理、收费标准配置、实时车位数据展示与停车记录查询，把车位检测、图像采集、号牌识别与收费记录整合进同一套可远程查看的闭环。
系统在 2025 年 4 月 完成整机联调，进出记录页存下的 13 条实测记录与五张车牌抓拍样本，就是这条链路真实跑过的痕迹。
1.1 系统技术架构
系统自上而下划分成应用层、服务层、网络层、控制层与感知执行层五个层次。
图 1 系统总体架构图
五层的关键分工是：相机只负责按快门与上传，主控只负责汇总车位状态与驱动舵机，车牌识别始终在服务端完成。这也意味着换一家识别服务、改一条计费规则，硬件侧一行代码都不用动。
1.2 系统功能结构
按部署位置划分为硬件系统、软件系统与交付服务三列。
图 2 系统功能结构图
三列之间只有一条边界：设备侧只做「检测 + 采集 + 执行」，号牌识别、计费规则与记录留存全部放在服务端。
二、硬件系统设计
2.1 硬件系统原理框图
整块板子的中心是 STM32F103C8T6 核心板模块，一侧是输入与采集：四路红外感应模块与 ESP32-CAM 摄像头模组，另一侧是输出与执行：SG90 舵机、OLED12864、蜂鸣器与三组车位指示灯，整机由 TYPE-C 取电口单口供电。
图 3 硬件系统原理框图
从框图可以看出本项目在硬件上的一个关键取舍：图像数据完全不经过主控。红外感应的 DO 只给主控一个边沿事件，真正触发拍照与上传的是模组自己 —— 收到指令后取景，把 JPEG 经 Wi-Fi 以 HTTP POST 直达服务端。主控既不是数据通道，也不需要在固件里解析图像。
2.2 硬件原理图
原理图用嘉立创 EDA 绘制，同时提供 pdf、png、json 与 schdoc 四种格式。本文的接线描述以 json 源文件中的网络标号为准。
图 4 硬件原理图
提示：解析原理图时建议直接读嘉立创 EDA 的json源文件。导出的 PDF 文字层只会包含已经连线的部分，而源文件里能取出「引出但未连接」的悬空网络标号。提取方式是从schematics[0].dataStr.shape这组字符串里，用\^\^([\d.\-]+)~([\d.\-]+)\^\^(\S+?)~取网络标号坐标，用spiceSymbolName\([^\]*)\` 取元件型号。
2.3 硬件实物
实物装配以洞洞板（万用板）作底板、杜邦线互连，核心板压在板面中部，四路红外感应模块经排针引出，OLED12864 挂在板面一侧，摄像头模组立在板上，整机由一根 USB 线供电与下载。
图 5 硬件实物总览
OLED 上实测显示四行：车位引导系统、车位总数：35个、剩余车位：33个、收费单价：4元。车位统计与费率是就地可见的，不需要打开网页也能看出车场当前的状态。
图 6 板载器件与 OLED 读数特写
车牌识别的输入是五张车头实拍样本：浙A·X7U36、闽F·UE988、川A·Y17J5、皖F·66666 与 京A·00000，全部为蓝底白字燃油车号牌，与网页端用户管理和进出记录里的牌照数据一一对应 —— 实时图像区里那些识别结果，就是从这类照片里认出来的。
2.4 引脚分配
| 连接对象 | 信号 | 引脚 | 说明 |
|---|---|---|---|
| 红外感应·车位 1（U5） | DO | PA1 | 恰好是 EXTI 第 1 号外部中断线 |
| 红外感应·车位 2（U6） | DO | PA2 | 恰好是 EXTI 第 2 号外部中断线 |
| 红外感应·车位 3（U7） | DO | PA3 | 恰好是 EXTI 第 3 号外部中断线 |
| 红外感应·出入场（U8） | DO | PA4 | 恰好是 EXTI 第 4 号外部中断线 |
| SG90 舵机（U4） | SIGNAL | PA8 | 即 TIM1_CH1，高级定时器通道 |
| OLED12864（U3） | SCL / SDA | PB6 / PB7 | 与硬件 I2C1 的默认分配完全一致 |
| OLED12864（U3） | VCC / GND | 5V / GND | 模块由 5 V 供电 |
| ESP32-CAM（U2） | IO1(TX) / IO3(RX) | PA10 / PA9 | 对应 USART1；模组 5V、GND 另行供电 |
| 有源蜂鸣器（BUZZER1） | 信号端 | PB15 | 另一端接地；PB15 是 SPI2_MOSI，本设计按普通 GPIO 驱动 |
| 车位 1 指示灯 | 红 / 绿 | PC14 / PC15 | 这两脚同时是外部 32.768 kHz 低速晶振的 OSC32_IN / OSC32_OUT |
| 车位 2 指示灯 | 红 / 黄 | PB0 / PB1 | 图纸 COLOR 标为 R / Y，实物为红绿双色（见缺口说明） |
| 车位 3 指示灯 | 红 / 黄 | PB10 / PB11 | 图纸 COLOR 标为 R / Y；这两脚同时是 USART3 的默认 TX / RX |
把这几根线排开来看，落点并不随意：
· 四路红外分别落在 PA1 / PA2 / PA3 / PA4，恰好是 EXTI 的 1~4 号中断线，四路互不冲突
· 显示屏 SCL / SDA 落在 PB6 / PB7，正是 硬件 I2C1 的默认分配
· 舵机信号 PA8 恰好是 TIM1_CH1，50 Hz、脉宽 0.5~2.5 ms 的周期信号可用硬件 PWM 直接产生
· 摄像头两线落在 PA9 / PA10，正是 USART1 的收发脚
· 六只指示灯分三组：车位1 用 PC14/PC15（兼作 32.768 kHz 晶振脚）、车位2 用 PB0/PB1、车位3 用 PB10/PB11（兼作 USART3 默认收发）
各路外设各归其位，主控这一侧的负担非常轻。
三、逐线核对原理图得到的四处判断
把嘉立创 EDA 源文件里的网络标号提取出来、与 PDF 文字层逐条对照后，有四处值得单独说明。
3.1 四路红外各自占一条外部中断线，互不冲突
四个红外感应模块的 DO 分别落在 PA1、PA2、PA3 与 PA4，而这四个脚恰好是 STM32F103 的 EXTI 第 1、2、3、4 号外部中断线 —— 四路各占一条，既不需要像引脚号撞车的方案那样牺牲其中一路改走轮询，也不会有两路共用一个中断入口时「一次触发分不清是谁」的问题。车位占用与车辆出入场都是「来了就要立刻记账」的事件，四路各自独占一条中断线，意味着任何一路的状态变化都不会被漏采。
3.2 显示屏的接线与硬件 I2C1 的默认分配完全吻合
OLED12864 的 SCL 接 PB6、SDA 接 PB7，而 STM32F103 的硬件 I2C1 默认功能分配正是 SCL = PB6、SDA = PB7，两者完全一致。这块屏因此具备直接调用片上 I2C1 外设的条件，不必再用通用 IO 去模拟时序 —— 对一块需要持续刷新车位数的屏来说，硬件外设的稳定性比软件模拟省心得多。
3.3 舵机刚好落在高级定时器的通道上
SG90 的信号线接在 PA8 上，也就是 TIM1_CH1。舵机要求的是 50 Hz、脉宽 0.5 ~ 2.5 ms 的周期信号，用一路高级定时器的通道直接产生最直接，不必额外占用通用定时器去凑节拍。本设计用舵机做入场方向引导，转动角度与车位状态绑定。
3.4 六只指示灯分在三组引脚上，其中两只兼作晶振脚
车位 1 用 PC14 / PC15，车位 2 用 PB0 / PB1，车位 3 用 PB10 / PB11。值得注意的是：PC14 与 PC15 同时是外部 32.768 kHz 低速晶振的 OSC32_IN / OSC32_OUT，PB10 与 PB11 同时是 USART3 的默认 TX / RX。本设计把这三组都当普通 GPIO 用，因此若将来要启用外部低速晶振或 USART3，需要重新分配这三组灯脚。蜂鸣器所在的 PB15 是 SPI2_MOSI，同样按普通 GPIO 驱动 —— 有源蜂鸣器只需高低电平，本来也不需要用 PWM。
以上四条并非对设计的质疑，而是对既有连线的如实描述 —— 本文只记录原理图上真实存在的连接，不对作者的意图作推测。
四、通信链路与数据交互
4.1 通信参数
| 链路 | 协议 / 方式 | 说明 |
|---|---|---|
| 无线承载 | Wi-Fi 2.4 GHz（STA 模式） | 默认热点名 8266wifi、密码 123456789；说明文件里特别注明需使用电脑开热点 |
| 图像上传 | HTTP POST（REST 方式） | 相机端把拍到的 JPEG 直接 POST 到服务端的上传接口，不经过主控转发 |
| 指令通道 | TCP Socket | 服务端实现 tcpsocket 服务端，与硬件周期性同步数据、下发指令 |
| 车牌识别 | 服务端调用百度在线车牌识别接口 | 号牌识别在服务端完成，识别结果回写停车记录；硬件侧不做识别 |
| 服务端技术栈 | jeesite 平台 + Java / SpringBoot / MySQL / Bootstrap | 网页端与管理接口都构建在这一套框架上，数据以 MySQL 持久化 |
| 固件开发 | Keil 5 | STM32F103C8T6 固件工程在 Keil 5 下编译并烧录 |
| 缴费入口 | 网页端弹出的缴费图形码 | 说明文件写明缴费时手机需连上同一个 8266wifi 热点，因此该入口只在同一局域网内可用 |
相机端保存的配置原文如下（局域网地址，仅供同网段调试参考）：
ssid:8266wifi pass:123456789 server IP:192.168.137.250 server port:19214 rest url:http://192.168.137.250:8889/f/esp32/upload debug mode:false word mode: Periodic photo taking
抓拍模式默认为周期拍照（Periodic photo taking），也可由红外感应触发单次抓拍。
4.2 数据交互时序
以「一辆车驶向出入口」为例，整个过程分成十二步：出入感应检测到车辆、边沿事件进主控、发出拍照指令、图像以 HTTP POST 直传服务端、服务端建立进出记录、调用百度在线车牌识别接口、号牌结论写入记录、结论经 TCP Socket 回传、主控合并车位占用状态判定、驱动舵机控制闸机、OLED 与指示灯刷新、记录落库。
图 7 系统数据交互时序图
这张图里有两处值得展开。第一处是「主控全程不搬运图像数据」：JPEG 从模组直接进网络，主控只是事件的触发者，采集链路在主控这一侧非常轻。第二处是「认车结论不依赖硬件」：识别接口的调用发生在服务端，硬件侧既没有模型也没有号牌库。
五、软件系统与界面功能
5.1 界面字段
| 界面分组 | 字段与说明 |
|---|---|
| 用户管理 | 姓名 / 电话 / 车辆牌照 / 更新时间 / 操作 — 按姓名与电话检索，右上角另有「+新增」；「车辆牌照」一栏把车主与车牌绑定起来 |
| 编辑用户 | 姓名 / 电话 / 车辆牌照 — 弹层页头写着「基本信息【手机号码将作为登录的账户信息】」，提交前为「保存」「关闭」两个按钮 |
| 车场闸机管理 | 终端编号 / 终端名称 / 安装地址 / 车位 1 / 车位 2 / 车位 3 / online / 更新时间 / 操作 — 登记每一台闸机终端的编号、名称、安装地址与三个车位的实时占用情况 |
| 系统配置 | 参数名称 / 类型 / 参数项 / 参数值 / 备注 / 更新时间 / 操作 — 以「参数名称 / 类型 / 参数项 / 参数值」四列维护收费单价与各停车场编号 |
| 实时数据展示 | 车位总数 / 空闲车位 / 闸机状态 / 收费价格 ＋ 三个车位卡 ＋ 车场参数设定 ＋ 实时图像 — 顶端给出更新时间与车场编号下拉，其后是四张统计卡、三张车位卡与车场参数设定区 |
| 进出记录查询 | 车牌 / 类型 / 用户 / 电话 / 入库照片 / 入库时间 / 出库照片 / 出库时间 / 停车时长(分钟) / 单价(元/小时) / 收费金额(元) / 闸机编号 / 备注 / 操作 — 一次进出留一条记录，同时带出车辆信息与收费信息，查询条件为车牌号码 |
侧边菜单共五项：用户管理 / 车场闸机管理 / 系统配置 / 实时数据展示 / 进出记录查询。其中「系统配置」只有 4 条记录，却决定了费率与车场规模。
5.2 登录页与实时数据展示
登录页标题「车位引导系统」，字段只有「登录账号」「登录密码」两项。
图 8 登录页与实时数据展示页
实时数据展示页顶端给出更新时间与车场编号，中部是四张状态卡与三个车位卡，下面依次是车场参数设定区与实时图像区。实测这一帧为：更新时间 2025-04-22 20:22:48、车场编号 停车场出入闸A、车位总数 3、空闲车位 0、闸机状态 关闭、收费价格 3元/小时，三个车位卡均为空闲。
必须说明：网页端「车位总数 3」是演示环境按三个模拟车位登记的口径，而终端 OLED 实拍的「车位总数 35个 / 剩余车位 33个」是屏幕固化的演示画面，两处口径不一致，本文如实并列、不作统一。
车场参数设定区共三组：收费价格填入数值后点确定即生效；远程开闸提供「每次开闸 / 常开 / 关闭」三档；缴费入口一栏提供「显示缴费码」按钮。实时图像区按时间横向排出最近五张车牌抓拍：皖F·66666、京A·00000、苏A·X7U34、闽F·UE988 与一张空位。
5.3 用户管理与车场闸机管理
图 9 用户管理页与车场闸机管理页
用户管理页实测注册了 5 条记录，车辆牌照依次为 陕A00000、川AY17J5、浙AX7U36、浙D88888 与未填写。编辑用户弹层的页头写着 基本信息【手机号码将作为登录的账户信息】，也就是说手机号同时承担账号与联系方式两个角色；「车辆牌照」一栏则把车牌与人绑定，供进出记录按「内部 / 访客」归类。
车场闸机管理页实测只有 1 台：终端编号 ZDBH01、终端名称 停车场出入闸A、安装地址 xxx广场、车位 1 / 2 / 3 均为 空闲、online 状态 在线、更新时间 2025-04-22 20:22:13。表格把三个车位的占用状态直接铺进列里 —— 加装第二台闸机时，后台不需要改代码，登记一条即可。
5.4 系统配置与缴费入口
图 10 系统配置页与缴费入口弹层
系统配置页共 4 条，逐条列出如下：
单价 tcs1 sfdj 3 <- 收费单价 停车场A tcs1 tc1 1 <- 车位数配置 停车场B tcs1 tc2 1 停车场C tcs1 tc3 1
费率与车场规模都以配置项形式落库 —— 改单价是改一条记录，加一个停车场是再加一条。
缴费入口弹层的结构是：顶部一行红字提示「请先连接电脑热点后再支付」，标题「支付停车费」，副标题「提前支付，出口不排队」，图形码下方注明支持的支付渠道（支付宝、APP 等）。把它与实时数据展示页的「显示缴费码」按钮连起来看，缴费这条支路的设计意图就清楚了 —— 局域网环境里车辆端要先连上热点，才能访问到支付页。
5.5 进出记录查询
图 11 进出记录查询页
实测该查询共 13 条记录，每页显示 20 条。可见样本里既有访客也有内部车辆：
京A00000 访客 （无用户无电话） 浙AX7U36 内部 萧萌萌 闽FUE988 访客 川AY17J5 内部 罗建政
其中一条出库于 2025-04-22 的记录完整走完了计费：停车 1 分钟、单价 4、收费金额 4、闸机编号 ZDBH01、备注「已缴费」；其余多数条目停车 0 分钟、单价 4、收费 0。
这张表有两处值得留意。一是「类型」一栏把车分成了「内部」与「访客」两类：内部车能在用户管理页找到车牌与人的绑定，访客车则只有车牌没有用户 —— 计费规则由此分岔。二是「入库照片 / 出库照片」两列都是缩略图，说明每一次进出都留了影像。
说明：本项目界面截图含真实手机号，已在交付前统一作不可逆遮蔽（马赛克 + 高斯模糊）。遮蔽后经高频细节能量自校验，各遮蔽区域降至原值的 0.1% 以下。
六、终端屏幕与车牌识别样本
硬件实拍里 OLED 读数清晰可辨，车牌样本与后台数据一一对应。
图 12 终端 OLED 读数与车牌识别样本
把这两组证据放在一起看，可以说清楚一件事：屏幕上的车位统计是主控写上去的实时状态，而识别样本里的号牌与进出记录页、用户管理页里的牌照字段完全一致 —— 整条「抓拍—识别—落库」链路的输入与输出都对上了。
七、系统视频展示
演示视频完整记录了系统从登录、查看车位状态，到车辆到达、触发拍照、服务端识别、闸机放行的全过程。
图 13 演示视频封面
视频里可以重点看三处：一是车辆到达检测位到屏幕出现识别结果之间的停顿，这段时间正是图像上传与车牌识别在服务端跑；二是实时数据展示页状态卡与车位卡的刷新，占用与空闲一目了然；三是 OLED 上车位总数与剩余车位的变化，它与网页端实时数据展示页是同一份状态的两种呈现。
八、交付内容
| 交付项 | 形式 |
|---|---|
| 硬件实物 | 已装配并完成联调的整机（洞洞板 + 杜邦线） |
| 程序源码 | STM32F103C8T6 固件工程与 Java 服务端 + 网页端工程 |
| 硬件原理图 | 嘉立创 EDA 源文件（json / schdoc）及导出的图像与文档 |
| 演示视频 | 系统完整运行的演示录像 |
| 技术支持 | 远程协助环境搭建、程序调试与小规模修改答疑 |
项目编号 X504201。本文所述系统已完成实测验证，相关技术问题可在评论区交流。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/flyaimo/article/details/166991877
