所有分类
主题 主题
平台 平台
我的工作台
userHead
注册时间 [[userInfo.create_time]]
创造力 [[userInfo.creativity]]
[[userInfo.remark]]
[[d.project_title]]
articleThumb
[[d.material_name]]
timelineThumb
进入工作台
折叠
所有分类 我的工作台
展开
【AI挑战赛第三轮】“健康码上行”之基于二哈标签识别的物联网智能道闸系统,助力新冠肺炎城市防控管理
Jacken Jacken 2020-03-27 13:55:02
5
1
简单
projectImage

      新冠肺炎疫情自年前爆发至今数月有余,我们从最初的“武汉加油·中国加油”到现如今的“地球加油”,所有人无疑经历了有生以来最严重的一次灾难。至今全球已确诊二十几万人,因疫情离我们而去的更是近万人,3月23日更是爆出全球单日新增确诊近4万人的惊人数据。目前我国也已经从“防控输出”转为“预防输入”的重大战略,疫情防控形势仍然非常严峻。

      在此次疫情中,城市管理者对于人员流动的管控也很是头疼。由于部分人的瞒报导致疫情防控功亏一篑的也数不胜数,如春节期间的“XX毒王”和春节后的“飞意大利看球赛事件”等等,由于新冠病毒的超长潜伏期和超强传染性再加上流动人员进入城市之前的不主动上报及瞒报等原因,导致疫情防控异常困难。

      基于此,我在目前全国多省普遍施行的“健康码”政策中受到启发,设计了这个基于二哈标签识别功能的物联网智能道闸系统,藉此探索和畅想在疫情防控中,如何最大化地杜绝因瞒报、谎报等人为因素导致的疫情失控问题。


【项目功能简述】

    该道闸系统可以装配在各个城市的进城道路上也可以装配在各个小区、商店出入口,作为一个区域性防控管理装置。居民通过APP申请专属健康码,在出入口处出示健康码通行,道闸系统会实时与后台联系,若发现该居民曾经到过预警城市中的地区,则不予以通行;当居民被允许通行后,该处的道闸系统会立即通过物联网向服务器上报当前通过该出入口的居民信息及该出入口位置信息,并在后台系统中形成记录。后台系统可以通过设置预警城市/地区,来实现对居民出入各个区域道闸时的智能排查,第一时间发现潜在危险,第一时间处理隐患,实现“智能预警,联防联控”的效果。

步骤1 步骤1
作品演示视频

先附上作品的演示视频,有一丢丢长!

材料清单 材料清单
1x
Gravity: 二哈识图(HuskyLens)
1x
掌控板
1x
micro:bit掌控I/O扩展板
1x
180°微型舵机
1x
纸板(或椴木板)、切割打孔工具、502胶水等若干
步骤2 步骤2
(一)程序部分

本作品分三阶段完成:程序编写及测试、实物手工制作装配、最终测试及演示视频录制。接下来先简单介绍下程序部分。


程序部分又分为3个小项目:基于Mind+舞台模式下的服务器端、手机APP端和掌控板硬件端。

步骤3 步骤3
(一)1、手机APP端的实现

手机APP端我是通过App Inventor来实现的,使用的是https://app.wxbit.com/平台,手机端主要功能就是申请健康码和出示健康码供道闸扫描识别。本来还想增加一个用户可以获取查看自己的历史轨迹的功能,但无奈对于App Inventor我也是半桶水/(ㄒoㄒ)/~~


手机APP端在首次启动后,显示的页面是申请健康码的页面,当申请完成后,则会跳转到健康码显示界面。

在这反思几点功能上的不足及往后可改进的方向:

①无法保存用户数据。当APP重启后,无法保留之前申请到的健康码,且同名字无法重新申请。

②无法查看本人历史轨迹。本人都去过哪些地方,无法在APP端看到。

③无法通过服务器实时获取申请的二维码。不知如何实现将图片从基于Mind+的服务器端通过TinyWebDB发送到手机端,所以目前的解决方案是将健康码的标签图片存储到APP内部,申请时通过与服务器指定参数的通信实现标签图片不重复的效果。

④界面UI没设计。


下方是APP端的界面布局

projectImage

当APP启动时,首先会进行屏幕初始化,判断当前用户是否已经拥有健康码,如果没有则显示申请健康码界面,如果有则直接显示健康码。

projectImage

下方是申请健康码部分的编程。在这里需要先去搭建TinyWebDB网络数据库,获取到服务器的数据通信接口。


TinyWebDB网络数据库可以使用这个:http://tinywebdb.appinventor.space/


projectImage

这里我们可以选择自己注册一个账号,也可以选择使用共享的share账号,我建议还是自己注册一个方便。


这是登录后的界面,我们主要需要用到的是服务器地址。


点击下图中的“数据浏览”,可以查看数据通信情况,便于我们前期进行通信测试。


projectImage

获得数据库服务器地址后,回到App Inventor继续编程,下面这部分就是实现在申请健康码时将申请信息上传到TinyWebDB网络数据库的功能。

projectImage

数据上传到TinyWebDB网络数据库后,基于Mind+的服务器端会实时监测并对数据进行接收、处理、保存等操作。

下面这部分则是获取健康码的脚本,测试中,我只在APP端存入6张标签图片,如何实现用户提交申请后获得的标签图片不重复呢?这就需要服务器端向TinyWebDB网络数据库回传数据,然后再由APP端接收并处理,来判定现在哪些标签图片已经被使用,哪些还可以用。

projectImage
步骤4 步骤4
(一)2、基于Mind+服务器端的实现

服务器端是这套系统的管理终端也是监控中心。主要功能有:存储用户申请信息及健康码ID、接收记录用户踪迹、设置预警城市、排查控制各卡口的通行状态。


这是基于舞台模式的,我们需要在扩展里添加TinyWebDB网络数据库的扩展,并在绿旗启动时先连接上TinyWebDB网络数据库,这里需要用到的是TinyWebDB网络数据库的API接口地址、用户名和密钥。


程序会循环监测TinyWebDB网络数据库端的数据变动情况,一有数据更新则会立即获取到本地进行相应的处理。

projectImage
步骤5 步骤5
(一)3、道闸硬件终端的功能实现

道闸主要功能就是利用二哈标签识别功能识别标签,并将识别到的信息上传到TinyWebDB网络数据库,由服务器端接收处理并根据服务器端回传的数据判断是否开启道闸放行。

这是基于Mind+的上传模式,切记!!先切换到上传模式再编程!!!


首先需要先添加几个扩展:(主控板)掌控板、(传感器)HUSKYLENS AI摄像头、(执行器)舵机模块、(功能模块)多线程、(网络服务)TinyWebDB、(网络服务)Wi-Fi


当掌控板启动时,需要先连接wifi——再连接TinyWebDB——最后初始化二哈引脚和切换二哈算法。这个顺序不能乱!!!特别是前两个的顺序!!!


下图是连接wifi和TinyWebDB网络数据库的设置参考:

projectImage

当一切准备就绪后,就开始循环监测,如有标签出现在画面中则进行识别(这里需要将二哈的标签识别开启“学习多个”功能,并事先将所有标签按照既定的设置顺序进行学习,一一对应),关于二哈标签识别学习训练请参考官方教程:传送门

【提醒:标签图片也请从上面的传送门中获取】


通过二哈获取到标签ID,将其上传到TinyWebDB,利用服务器端进行识别处理,返回标签背后登记的用户信息到掌控板,并将其显示出来。同时服务器端也会返回是否放行的数据指令,掌控板会根据指令判断是否放行。


如果允许通行,则会亮绿灯并播放音乐,同时在打开道闸的同时向服务器端上传本道闸的位置信息,服务器端则会在“用户轨迹”列表中生成最新的用户踪迹。

如果拒绝通行,则亮红灯并播放音乐。


以下则是掌控板的脚本:

projectImage
步骤6 步骤6
(二)实物制作部分

由于家里工具匮乏,然后又作死买了3mm厚的椴木板……用小电摩+美工刀愣是切割到手指发麻/(ㄒoㄒ)/~~


通过下面凌乱的电脑桌就能看到我是多么的缺乏工具😟

projectImage

首先是掌控板及扩展板的底座制作,精度不好控制,后面发现做的不够高,在接上舵机和二哈数据线后发现顶板有点盖不下去。

供电方面我使用了一个3.7v的锂电池,在底座上我开了个孔,实现所有线缆内藏。

projectImage
projectImage

这是掌控板顶部盖子和二哈支撑板的一个设计/(ㄒoㄒ)/~~开孔真的很恐怖。。。。

projectImage
projectImage

底部做了一个小箱子,一是可以用来放电池,二是舵机也需要固定的地方。后面的盖子我用魔术贴固定,方面取下来给锂电池充电等。

projectImage

蹬蹬……大功告成,emmm是丑了点~~~

projectImage

掌控扩展板使用外接电池供电后,二哈不识别状态下是够的,但是二哈开始识别标签时,则会在识别完成后重启,这是供电不足的原因,所以我又外接了一个充电宝给二哈独立供电(手头上没有microusb口的锂电池电源线,不然也可以把给二哈供电的电池放到下面的小盒子里)

projectImage
步骤7 步骤7
大功告成
projectImage

这里在掌控扩展板电源开关开孔处忘了弄个杆子出来,所以要开关掌控板时需要弄个牙签进去拨动(哈哈哈~~~)


最后~~勤劳的小蜜蜂来打扫卫生🤭

projectImage
步骤8 步骤8
附上项目编程部分的源文件
Makelog作者原创文章,未经授权禁止转载。
5
1
评论
[[c.user_name]] [[c.create_time]]
[[c.parent_comment.count]]
[[c.comment_content]]