安全是我们的首要任务。在美国,每座商业写字楼都配备了烟雾探测器、火灾报警器和洒水装置。当火警响起时,大楼租户应立即撤离大楼;如果出现龙卷风等恶劣天气,火警系统会指示大楼租户前往地下室“就地避难”。
时不时地,有些人会无法撤离建筑物或无法前往就地避难地点。原因包括:
消防员接受过“清理”建筑物的培训。他们将进入每个房间并确认没有人在里面。然而,这个过程通常需要5~10分钟,期间困在里面的人情况可能会恶化。
技术可以提供帮助。在我的设计中,每个房间都有一个传感器报告里面是否有人,消防员可以使用这些信息来确定进入这些房间的优先顺序。
此屏幕说明了消防员可能从系统中看到的内容。共有三个房间,但传感器读数显示房间 1 更有可能有人,因此消防员应首先进入房间 1。
我的设计使用 D6T 传感器来检测人的存在。D6T 是一款 MEMS 热传感器。D6T 可以将它前面的区域“看”为 16 个像素的 4x4 网格,并测量每个像素的温度。D6T 在传感器内部还有一个参考温度传感器。由于人体的温度高于环境温度,当某些像素点的温度读数高于参考温度时,表明可能存在人体。
许多现有应用程序(例如防盗警报器)使用 PIR 传感器来检测人员的存在。与PIR相比,D6T有一个独特的优势:D6T能够检测静止的人员,而PIR只能检测运动。此属性在建筑物疏散应用中很重要,因为那些未能疏散建筑物的人可能不会移动。
该设备由 Azure Sphere MT3620 板和 D6T 传感器组成。D6T是一个使用5V供电和逻辑电平的I2C传感器设备;正如我测试的那样,它在 3.3V 电压下无法正常工作。因此,需要一个电平转换器来连接 Azure Sphere 的 mikro BUS 1 和 D6T 传感器之间的 SDA 和 SCL 线。
为了便于测试,我还将加载了“WiFiTelnetToSerial”示例固件的 ESP8266 连接到 Azure Sphere 的 mikro BUS 2 上的串行线路,以便我能够通过 telnet 无线读取调试消息。
在软件方面,我尝试了 Visual Studio 一段时间,但认为PlatformIO是更好的选择,因为它提供了更高级别的 API,使我能够更多地关注业务逻辑而不是低级别的细节。程序逻辑很简单:
在软件开发期间,我必须为 Azure IoT Central 连接和读取 D6T 传感器构建 Arduino 库。
Azure Sphere 可以连接到 Azure IoT HUB 或 Azure IoT Central。我掷硬币决定使用 Azure IoT Central。
Azure IoT Central 上的设置过程包括:
在完成这些设置并连接传感器后,我们可以在仪表板上看到传感器读数:
当需要疏散建筑物时,消防员可以打开仪表板查看哪些房间的读数非零。非零读数表示有人可能在该房间内,因此他们可以优先访问该房间。
Azure IoT Central 每台设备收费 2 美元,每百万条消息收费 5 美元,免费套餐包含 5 台设备和每台设备 50000 条消息。为了保持在免费套餐内,传感器每 52 秒只能发送一个读数,这对于分秒必争的安全应用来说是不够的。目前,我的程序每秒发送一个读数。一栋拥有 100 个房间的大楼的运营成本为每月 1461 美元,如果它可以挽救一条生命并避免诉讼,那么这个成本并不高。
可以通过两种方式降低成本:
我在我的公寓里测试了这个系统。我发现 D6T 可以有效地检测到我的存在,但前提是灯亮着。如果房间完全黑暗,D6T 就看不到我。因此,该方案对于商业楼宇,在房间有人时开着办公灯是有用的,但对于居民睡觉时可能会关灯的住宅楼宇来说是无效的。
如果我将一杯热茶放在 D6T 传感器前面,就会出现误报。然而,这在实际部署中并不是主要问题:当传感器安装在墙上时,热茶杯只能触发一个像素。消防员可以首先对热像素数量较多的房间作出反应,因为较高的数字表明那里很可能有人。
出于安全原因,我无法在建筑物实际着火时测试系统的有效性。
我开发了一种传感器设备来协助建筑物疏散。它可以告诉消防员哪些房间内可能还有人,让他们在清理建筑物时优先进入这些房间。
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉
全部0条评论
快来发表一下你的评论吧 !