本文章来自程序汪背后的私活小团队，无人自助洗宠物的项目，希望把这些真实案例分享出来，大家能学到点东西，列如软件硬件怎么对接，商业项目具体怎么评估价格，无自助洗宠机方案是什么样的等等。

声明：本身洗宠物机器硬件是成熟的第三方产品无需开发，只需开发软件端并跟硬件对接即可，硬件怕侵权暂时用AI图片取代，某宝上已经有许多现成的自助洗宠机

开发人员

• 前端 技术栈 vue 主要任务小程序及PC端页面
• 后端 技术栈 springboot
• 硬件 自助洗宠机 、控制板
• 通讯协议 MQTT、TCP服务
• 开发周期40天
• 开发人数 2人
• 整体研发费用是9万 （8W软 1W硬）
• 走的正规合同
• 云服务器1台（后面根据情况增加）
• 维护费 6000/年

后端技术选型

• 核心框架：Spring Boot
• 数据库连接池：Druid
• 缓存：redis
• 数据库：mysql
• 设计一个无人自助洗宠物机系统，结合小程序作为前端交互界面和Java作为后端服务，是一项涉及软硬件集成、用户体验设计、安全控制及数据管理的综合项目。下面是一个大致的设计框架：

1. 系统架构

• 前端（小程序）：负责用户交互、预约、支付、监控宠物洗浴状态等功能。可以使用微信小程序或支付宝小程序等平台开发，利用其丰富的UI组件和API接口简化开发流程。
• 后端（Java）：处理业务逻辑、数据库操作、与硬件设备通信等。可以采用Spring Boot框架快速搭建RESTful API，便于前后端分离和微服务架构的实施。
• 数据库：存储用户信息、预约记录、交易记录、设备状态等数据。可选MySQL或PostgreSQL等关系型数据库，或根据实际需求思考使用NoSQL数据库如MongoDB。
• 硬件接口：与洗宠机器人的控制单元通信，实现远程控制洗浴流程、调节水温、吹风干燥等功能。可能通过MQTT协议、HTTP请求或专门的硬件控制器实现。
• 安全与监控：确保用户数据安全，实现系统稳定运行。包括但不限于HTTPS加密传输、登录验证、支付安全、视频监控宠物洗浴过程等。

2. 功能模块设计

1. 用户管理：注册/登录、个人信息管理、宠物资料录入。
2. 预约服务：查看附近洗宠机位置、选择服务套餐、预约时间。
3. 支付系统：集成微信支付、支付宝等第三方支付接口，支持预付费和后付费模式。
4. 设备控制：小程序端发送指令控制洗宠机开始/停止、调节水温和风力等。
5. 实时监控：摄像头监控洗宠过程，用户可通过小程序观看，增加安全性与互动性。
6. 评价与反馈：服务结束后，用户可对体验进行评价，系统收集反馈用于优化服务。

3. 技术选型提议

• 前端：微信小程序小程序 + uni-app（跨平台开发框架）
• 后端：Spring Boot 、MyBatis（ORM框架）
• 数据库：MySQL + Redis（缓存）
• 消息队列：RabbitMQ（异步任务处理、解耦）
• 安全框架：Spring Security + JWT（权限验证）
• API文档：Swagger UI

4. 注意事项

• 用户体验：设计简洁易用的用户界面，思考到不同年龄段用户的操作习惯。
• 宠物安全：确保机器设计充分思考宠物体型、行为特点，避免伤害。
• 数据保护：严格遵守数据保护法规，确保用户隐私安全。
• 运维与故障处理：建立有效的监控体系和快速响应机制，确保系统稳定运行。

通过这样的系统设计，可以提供一种便捷、安全的无人自助宠物洗浴服务，提升宠物主人的体验，同时也为宠物服务行业带来创新。

项目背景

发现木有生小孩的越来越少，养猫猫狗狗的越来越多，特别是大城市里养小动物的超级多，许多狗狗过的比打工人都舒服，包吃包住包看病目前又来了一个包洗澡神器（无人自助洗宠物机），甲方本来就有洗宠机器只是想定制开发自己个性化需求，于是我们就把软件部分重新开发了下，主要涉及小程序、PC端管理后台、跟硬件的通讯接口对接（硬件接口本来是支持的需要开发控制而已）

1. 宠物数量增长：随着经济水平提高和生活方式的变化，越来越多的家庭开始饲养宠物，特别是城市中的宠物猫狗数量显著增加。这直接增加了对宠物护理服务的需求，包括洗澡服务。
2. 便捷性需求：现代生活节奏加快，宠物主人可能难以抽出时间带宠物去传统的宠物店排队等候洗澡。无人自助洗宠机提供了一个快速、灵活的选择，宠物主人可以根据自己的时间安排，随时带宠物进行清洗，节省了等待时间。
3. 成本效益：相比传统宠物店，无人自助洗宠机往往价格更加亲民，能够为宠物主人节省必定的费用，尤其是对于频繁需要洗澡的宠物来说，这种经济高效的解决方案更受欢迎。

综上所述，无人自助洗宠物机项目凭借其便捷性、经济性、个性化服务和适应健康安全需求等优势，正逐步获得市场认可，展现出广阔的市场前景。

核心流程

程序汪还是画个简单的流程图吧，方便大家理解，真实代码逻辑还是复杂的，这里简化了

无人自助洗宠机

甲方本来就是厂家（硬件部分），只是软件部分需要定制，自带的软件甲方感觉不好

下图这个屏幕也是一个APP定制，硬件涉及平板串口通讯，小狗狗洗澡的时候平板可以实时监控的

硬件中也配置有物联网卡，后端系统会维护数据

一 接口说明

这些软件主要就是控制硬件的阀门就可以，如上图 硬件阀门控制着（吹风、清洗、护理、香波、开门、关门等核心操作）

4.5 写阀门控制

讨论：由于CJ/T 188-2004标准没有控制阀门的控制码，需要自定义。

聚焦器——>表计

控制码（CTR_3）：2Ah（自定义）；

数据长度：L = 04h；

数据标识（DI0 DI1）：A017h；

序列号：SER；

帧数据：

字节	Code	描述
0	68h	长帧开始标志
1	T	表计类型代码
2-8	A0-A6	表计地址
9	2Ah	CTR_3
10	L	数据域长度L = 04h
11-12	A017h	数据标识DI0-DI1
13	SER	序号（00h） 01吹 02 洗 03护理 04 开关
14	55h/99h	开/关阀门控制操作
15	CS	校验和
16	16h	帧结束

例：4.5写阀门控制68 40 01 00 00 05 08 00 00 2A 04 A0 17 00 55 F0 16 （针对电表–开阀）

顺序	0	1	2–8	9	10	11-12	13	14	15	16
说明	68h	T	A0-A6	2AH	L	A017h	SER	开/关	CS	16h
实例	68	40	01 00 00 05 08 00 00	2A	04	A0 17	00	55	F0	16

表计——>聚焦器

控制码（CTR_4）：A5h（自定义）

数据长度：L = 05h；

数据标识（DI0 DI1）：A017h；

序列号：SER；

帧数据：

字节	Code	描述
0	68h	长帧开始标志
1	T	表计类型代码
2-8	A0-A6	表计地址
9	A5h	CTR_4
10	05h	数据域长度
11-12	A017h	数据标识DI0-DI1
13	SER	序号（00h）
14-15	ST	状态（S0-S1）（S1置为ff）
16	CS	校验和
17	16h	帧结束

聚焦器根据收到的内容，应答正确，或没有应答。

例：表计应答：68 40 01 00 00 05 08 00 00 A5 05 A0 17 00 00 FF 16 16 （针对电表）

顺序	0	1	2–8	9	10	11-12	13	14-15	16	17
说明	68h	T	A0-A6	A5H	L	A017h	SER	ST	CS	16h
实例	68	40	01 00 00 05 08 00 00	A5	05	A0 17	00	00 FF	16	16

状态字解析说明：CJ/T 188-2004标准中的ST状态字占2个字节，第一字节最低2位已定义了阀门3个状态和第3位已定义电池电压2状态，第4、5位为保留，而第一字节的其它位和第二个字节由厂商自定义。在本协议中用第6位定义为IT05的2状态，而最高2位定义为报警器的3状态，而第二字节作为保留字节。具体定义如下表所示：

	D0	D1	D2	D3	D4	D5	D6	D7
定义	阀门状态		电池电压	——-	——	IT05状态	报警器状态
说明	00-开 01-关 11-异常		0-正常 1-欠压	保留	保留	0-上电 1-未上电	00-报警 01-上电 11-未上电

小程序

小程序功能跟以前我们开发的充电宝项目差不多，核心也是选择相应套餐消费，消费时间结束订单完成，各种营销啊充值什么的功能都差不多。

PC端

预定球场预定台球等等各种需要场地的运动都可以用类似的系统改吧改吧，下面就是当时拿羽毛球篮球的预定系统稍微修改修改，核心功能都是定场管理 订单管理 其他权限 会员 代金券都是电商系统通用功能

订单表结构说明DROP TABLE IF EXISTS `order`;
CREATE TABLE `order` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `user_id` int(11) NOT NULL DEFAULT 0 COMMENT '用户ID',
 `order_no` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '' COMMENT '订单号',
 `trade_no` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '' COMMENT '流水号',
 `money` decimal(10, 2) NOT NULL DEFAULT 0.00 COMMENT '金额（元）',
 `note` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '' COMMENT '备注',
 `type` tinyint(2) NOT NULL DEFAULT 1 COMMENT '支付用途（1,支付预付金；2，补交费用）',
 `scenes` tinyint(1) NOT NULL DEFAULT 1 COMMENT '支付场景（1微信小程序，2支付宝小程序，3安卓app，4苹果app）',
 `way` tinyint(1) NOT NULL DEFAULT 1 COMMENT '支付方式（1，微信app支付；2微信小程序支付；3支付宝app支付，4支付宝小程序支付）',
 `status` tinyint(1) NOT NULL DEFAULT 1 COMMENT '支付状态（1，未支付；2，已支付；）',
 `addtime` int(10) NOT NULL DEFAULT 0 COMMENT '添加时间',
 `paytime` int(10) NOT NULL DEFAULT 0 COMMENT '支付时间 （退款时间）',
 `log_id` int(11) NOT NULL DEFAULT 0 COMMENT '使用订单ID ',
 `refund_money` decimal(10, 2) NOT NULL DEFAULT 0.00 COMMENT '退款金额',
 `refund_time` int(10) NOT NULL DEFAULT 0 COMMENT '退款时间',
 `refund_no` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '' COMMENT '退款单号',
 `is_refund` tinyint(1) NOT NULL DEFAULT 1 COMMENT '退款状态（1，无退款；2，退款成功；3，退款失败）',
 `refund_note` varchar(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '' COMMENT '退款失败缘由记录',
 `hand_money` decimal(10, 2) NOT NULL DEFAULT 0.00 COMMENT '手续费',
 `coupon_id` int(11) NOT NULL DEFAULT 0 COMMENT '代金券id',
PRIMARY KEY (`id`) USING BTREE,
 INDEX `user_id`(`user_id`) USING BTREE,
 INDEX `order_no`(`order_no`) USING BTREE,
 INDEX `log_id`(`log_id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 725361 CHARACTER SET = utf8 COLLATE = utf8_general_ci COMMENT = '订单表' ROW_FORMAT = COMPACT;