ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

一个Demo如何讲清无人零售三端闭环-超级无人售货机全景解读

一个Demo如何讲清无人零售三端闭环-超级无人售货机全景解读 01-一个Demo如何讲清无人零售三端闭环-URM Ultra全景解读作者黒漂技术佬系列URM Ultra 方案理念与架构篇大家好我是黒漂技术佬。今天开一个新坑——讲讲我自研的无人零售整合方案URM Ultra。先别被这个名字吓到。“URM” 你可以理解成 Ultra Retail Machine 这一套体系的简称“Ultra” 是想表达整合到极致的意思把无人售货机、无人车、机械臂三样硬核设备塞进同一套软件系统里跑通一条从卖货到补货的完整闭环。很多新手一听到无人零售脑子里就一个画面小区门口那个扫码开门的柜子。但真正落地一套无人零售系统远不止一个柜子那么简单。货卖完了谁去补补货的人或者车怎么调度仓库里成百上千件商品谁去分拣、谁去往柜子里塞这套链路如果全靠人那就不叫无人了。这篇文章就带你从项目名和整体定位出发把 URM Ultra 的全景先摊开看一遍。后面几篇我会逐个端深挖。一、先说人话URM Ultra 到底解决什么问题传统无人售货柜痛点其实很碎痛点说明补货靠人货道空了运营得开车去现场开门、塞货、关门费时费力调度靠喊哪台柜子快空了、哪台车有空全靠人工盯后台上货靠手仓库里成箱的商品靠人一箱箱搬到车上、再一件件塞进货道识别不统一有的柜子靠重力、有的靠 RFID视觉识别又各接各的算法URM Ultra 的野心想把上面四件事全部无人化售货机负责卖纯视觉识别 免密支付无人车负责运从前置仓把货送到柜子点位机械臂负责上在前置仓分拣、到柜子点位把货塞进货道。三者由一个Spring Boot 后台统一调度再加一个微信小程序给消费者下单。于是整套系统就有了销售 → 消耗 → 补货 → 上货的自循环。划重点URM Ultra 的定位是可二次开发的 Demo。它把业务域、状态机、任务编排都真实写出来了但刻意没有上微服务网关、鉴权中心那一套重基础设施。目的很朴素——让你能跑起来、读得懂、改得动。二、四个工程各管一摊光有后台还不够真实系统一定是多端协同。URM Ultra 一共拆成4 个工程技术栈刻意选得亲民端工程名技术栈一句话职责后台urm-serverJava 17 / Spring Boot 3.2 / Spring Data JPA系统的大脑管商品、订单、设备、车辆、机械臂、补货配送消费端urm-mini微信小程序原生消费者扫码、选购、下单、退款设备端 1urm-vehiclePython 3仅标准库无人车仿真 Agent心跳、领任务、执行、上报设备端 2urm-robotPython 3仅标准库机械臂仿真 Agent分拣、补货、上货几个新手容易懵的点我顺手解释一下为什么后台用单体一个工程而不是微服务因为我参考的体系urm-cloud是微服务但 Demo 阶段把 74 个 Java 文件全塞一个工程里按业务域分包product / device / order / vehicle / robot / replenish / vision / payment你 clone 下来直接mvn就能跑不用先搭 Nacos、网关。等以后真要上生产按包一切就能拆。为什么设备端用 Python 标准库、不引 requests无人车、机械臂本质是边缘设备很多跑在 ARM 板子上环境越干净越好。这里只用urllib发 HTTP模拟心跳 领任务 上报三板斧零依赖就能跑重点是讲清楚设备接入的模式而非堆功能。数据库用 H2 还是 MySQL默认 H2 内存库启动即灌演示数据零配置生产切 MySQL 只需改配置建表脚本已备好。这就是Demo 友好和生产可用的折中。三、三端角色分工卖、运、上把三个硬件端拉出来单列一张表职责就清楚了┌─────────────┐ 消费者 ──▶ │ 无人售货机 │ 卖视觉识别 免密扣款 └──────┬──────┘ │ 库存下降 ▼ ┌─────────────┐ ┌─────────────┐ │ 后台调度 │──────▶│ 无人车 │ 运前置仓→柜机点位 └──────┬──────┘ └──────┬──────┘ │ │ 到达点位 ▼ ▼ ┌─────────────┐ ┌─────────────┐ │ 机械臂 │◀───────│ 分拣上货 │ └─────────────┘ 上塞进货道端在闭环里的角色关键能力来自需求无人售货机前端销售纯视觉识别、双门 / 2 路锁 / 4 摄、微信支付分免密无人车物流执行补货、配送、前置仓中转机械臂仓库 / 上货执行分拣、补货、给设备上货注意一个微妙关系机械臂不是独立作战而是和无人车打配合。无人车把整批货从仓运到柜子旁边机械臂再负责把货塞进具体货道。这一段我会在第 05 篇细讲。四、端到端五步闭环本文核心整套系统最值得讲清楚的是这条端到端闭环。我把它拆成五步每一步都对应真实的代码链路[1] 上架 ──▶ [2] 扫码 ──▶ [3] 识别 ──▶ [4] 扣款 ──▶ [5] 低库存补货上货 运营配货 用户开柜 视觉算商品 免密扣款 自动派车臂第 1 步上架运营侧运营在后台维护商品、把商品绑定到售货机的货道slotNo。一台柜子有几个格子、每个格子放什么、容量多少、当前库存多少全部由后台的设备商品模块管。这是后续一切的起点。第 2 步扫码消费侧消费者用小程序扫柜子上的二维码二维码内容就是设备编号。小程序拿到编号后跳到该设备的商品页。这一步本质是把物理柜子和后台里的 Device 记录对上号。第 3 步识别设备 后台用户开门拿货、关门。关门瞬间柜内 4 个摄像头采集画面后台调用视觉识别服务输出哪个货道、拿了什么商品、拿了几个、置信度多少。第 4 步扣款后台 支付后台拿着识别结果一次性完成生成订单 → 微信支付分免密扣款 → 扣减货道库存。用户全程拿完就走不用掏手机付款。第 5 步低库存补货上货三端联动某货道库存低于阈值后台自动生成补货计划派发时同时生成无人车补货任务 机械臂上货任务。车把货运到、臂把货上架库存恢复。闭环完成进入下一轮。这五步里[1]~[4] 是卖货子闭环[5] 是补货子闭环。两个子闭环合起来就是无人零售的永动机。五、后台用三个 API 前缀把端拧成一股绳新手常问四个工程之间到底怎么通信答案在urm-server的路由设计上。后台对外只暴露三类前缀前缀面向谁干什么/admin-api/**运营后台商品、设备、订单、车辆、机械臂、补货配送的增删改查/app-api/**小程序设备列表、下单、我的订单、退款/device-api/**三个设备 Agent心跳、领任务、上报状态HTTP 模拟 MQTT把人操作的“消费者用的”设备上报的三股流量用 URL 前缀切开逻辑极度清晰小程序 ──/app-api──▶ ┌──────────────┐ ──/device-api──▶ 无人车 Agent 运营端 ──/admin-api─▶│ urm-server │ 机械臂 Agent └──────────────┘ ──/device-api──▶ 售货机 Agent设备接入这里有个设计巧思用 HTTP 模拟 MQTT。真实物联网设备一般走 MQTT发布/订阅但 Demo 阶段用普通 HTTP 接口就能把心跳→领任务→上报这套状态机跑通你本地起一个 Python 脚本就能联调不用先搭 EMQX broker。等真上生产把device-api这层换成 MQTT 即可业务 Service 一行不用改。六、为什么是 Demo而不是一上来就微服务写代码最忌过度设计。URM Ultra 在几处做了明确的取舍我列出来给你参考取舍选了啥为什么单体 vs 微服务单体按域分包跑起来零运维按包可平滑拆分H2 vs MySQLH2 默认MySQL 预留零依赖演示生产切库有脚本Mock 支付 / 识别接口抽象 Mock 实现链路先通真实微信 / 算法后接鉴权Demo 不接生产再补 OAuth2 / 多租户这些取舍不是偷懒而是把核心业务闭环和生产级基建解耦。Demo 阶段你该验证的是三端能不能闭环而不是网关稳不稳。七、怎么跑起来看效果极简版后台cd urm-server后mvn起项目默认 H2 自动灌 2 台柜子、2 台车、2 台臂、1 个前置仓的演示数据。设备端分别跑urm-vehicle、urm-robot两个 Python 脚本它们会自己心跳、抢任务、上报。小程序用开发者工具导入urm-mini把 baseUrl 指到后台即可。具体命令和接口清单去看项目里的部署文档、API 文档本篇只讲全景。八、本系列后续这篇把全景铺开了后面四篇我会逐个端庖丁解牛第 02 篇从一份原始需求文档怎么翻译成软件方案纯视觉、安卓工控、支付分免密第 03 篇售货机的硬件长相双门两路锁四摄怎么变成后台的一张Device表第 04 篇无人车——前置仓与补货配送任务的枢纽第 05 篇机械臂——仓库里最后十米的上货执行者。下一篇见。
返回列表