MuSa物联网开源案例

描述

项目介绍

MuSa是由Silvia Del Piano、Stefano Foti和Gianmarco Zizzo为罗马大学 Sapienza 的物联网 2020 课程开发的项目。

这个项目最初是为“ Mu seo dell'Arte Classica Sa pienza”设计的，其目的是提供个性化的旅游，并通过他们的智能手机向用户提供信息。

MuSa是如何活过来的——问题

我们预计 MuSa 会考虑参观者在参观博物馆时遇到的许多公共问题，例如：

• 有限的时间进行全面访问
• 在他的道路上遇到一些与他的兴趣不符的艺术作品
• 想要了解更多关于歌剧的细节，但同时出于多种原因他不喜欢有实体或音频指南

同时，我们想到了策展人：

• 除了提供一些吸引游客下次再来的服务的事实之外，还需要对最受赞赏的艺术品和访问者的路径进行一些统计

由于 MuSa 的基本概念是以用户为中心，因此我们从这些方面着手构建能够满足用户需求的东西。

该主题的先前经验

个性化游览的主题已经在智能博物馆中体验过，但我们几乎没有发现现代和充分发展的东西。例如，大多数游览方式都包含固定的艺术品列表，对于每个人或来自同一预定义用户的访客都是一样的团体（例如游客、学生、专家团体）。第二个问题是在线旅游与现场/多媒体旅游之间缺乏联系，通常分为两个旅游，没有任何联系。这两个问题成为构建个性化旅游的主要挑战。显然，智能博物馆中与艺术品的交互和信标的使用也已经经历过；无论如何，有很多方式可以为这两个方面赋予生命。我们在文档中对以前的经验进行了深入分析，与相关参考资料。

MuSa 解决方案 - 概述

MuSa 收集和分析有关游客及其旅行的信息，并提出定制的旅程，以提供一种享受艺术的新方式。在开始时，每个用户都应该填写一份简短的调查，以收集有关其个性的信息。然后穆萨会问他是想享受定制的旅行还是只是帮助收集数据。当然，用户也可以选择根本不使用该系统。当用户只想为数据收集做出贡献时，他将开始自己在博物馆内旅行，将智能手机放在口袋里以非侵入性方式收集数据。当用户想与 MuSa 一起享受游览时，他会按照 MuSa 向他展示的定制建议开始探索博物馆。

建筑学

在本节中，您可以找到我们项目中存在的所有主要硬件和软件的列表。

• 网络图
  在分析单个硬件和软件组件之前，有必要先看一下整个网络图。在每件艺术品或艺术品集群附近，都有一个 ESP32 板，通过 Android 从用户的智能手机捕获信标应用程序。ESP32 板在可变时间内将信标发送到 Raspberry Pi 网关；网关每五秒钟将预处理的数据发送到托管后端的云，最终将响应应用程序的请求。

现在我们将一一分析系统的组成部分：

• ESP32
  ESP32是一系列低成本、低功耗的片上系统微控制器，集成了 Wi-Fi 和双模蓝牙。它能够在工业环境中可靠运行，并由先进的校准电路供电，使其能够动态消除外部电路缺陷并适应外部条件的变化。ESP32 专为移动设备、可穿戴电子产品和物联网应用而设计，可实现超低功耗。它可以作为一个完整的独立系统运行，并且可以与其他系统连接以提供 Wi-Fi 和蓝牙功能。在我们的项目中，ESP32 起着关键作用。我们首先需要在每件艺术品附近安装一个 ESP32，用于接收来自用户智能手机的信标并进行跟踪；然后，该板每五秒向主网关（Raspberry Pi）发送一条带有收集数据的消息。

• Raspberry Pi
  Raspberry Pi是一系列小型单板计算机。它的硬件已经经历了几个版本的演变，这些版本在中央处理器的类型、内存容量、网络支持和外围设备支持方面有所不同。无论如何，它非常强大。在我们的项目中， Raspberry Pi 充当 ESP32 和 Microsoft Azure 之间的网关；它对接收到的数据进行预处理，进行一些密集的边缘计算（“IoT 方面”部分中的更多信息），然后通过 Azure IoT Hub 将它们发送到云端。

• LedRGB
  我们使用了普通的 RGB LED，当然，还有很多其他的解决方案可以替代它。在我们的项目中，网关在数据处理期间使用 MQTT 消息将 RGB LED 打开为绿色。红色是为问题、启动阶段和状态保留的，因此它由董事会直接管理。
• Microsoft Azure 云服务
  Azure是 Microsoft 创建的一种云计算服务，用于通过 Microsoft 管理的数据中心构建、测试、部署和管理应用程序和服务。它提供软件即服务 (SaaS)、平台即服务 (PaaS) 和基础架构即服务 (IaaS)，并支持许多不同的编程语言、工具和框架，包括 Microsoft 特定和第三方软件和系统。对于我们的项目，选择使用 Azure 作为云服务是我们为同一 IoT 课程分配了四次作业的结果，这使我们能够试验多种云服务并进行比较。我们认为 Azure 提供了比 ThingsBoard 更有用的功能，而且我们认为它比 Amazon Web Services 更易于使用。

• MQTT/MQTT-SN
  MQTT是一种用于小型传感器和移动设备的轻量级消息传递协议，针对高延迟或不可靠的网络进行了优化。在我们的项目中，我们使用 MQTT-SN 进行 ESP32 板和树莓派之间的通信，使用 MQTT 进行树莓派和云之间的通信。
• 低功耗蓝牙 (BLE)
  低功耗蓝牙是一种无线个人区域网络技术，旨在用于医疗保健、健身、信标、安全和家庭娱乐行业的新型应用。在我们的项目中，我们使用 BLE 进行设备之间的信标交换，针对室内定位。我们做了一些额外的添加来尝试提高跟踪的精度，我们稍后会讨论它们。

• Android App
  MuSa 的服务是通过一个用Java 开发的Android App 提供的。当访问者想要使用 MuSa 时，首先，应用程序会通过欢迎问卷对用户进行描述，然后向他推荐定制的游览，如果用户接受，他将收到游览中出现的每件艺术品的信息和详细信息，当他靠近它时。

物联网元素

由于该项目从物联网课程中汲取生命，因此它充满了物联网元素和主题。

• 数据收集和数据分析是物联网的两个主要目标。通过 MuSa，我们收集有关访客和用户的信息有几个原因，例如提供个性化旅游并通过访客的行为改善这些旅游。即使在我们的项目中没有计划，策展人也可以将收集到的数据用于其他几个方面，比如重新组织博物馆的艺术品定位，简单地分析这些数据。
• 边缘计算是物联网中广泛使用的计算范式；我们对收集到的数据进行预处理，以结构更好的方式将它们发送到云端，并节省发送的消息数量，以更好地利用云端的免费计划。当其中一个 ESP32 每秒捕获用户的信标在可变时间临时存储它们，这取决于博物馆中有多少用户，直到最多五秒钟，将它们发送到网关。这已经是一种预处理，因为如果每次都将这些数据直接发送到云端，那么免费计划就会提前很多。我们在文档中对消息的保存进行了进一步的计算。当消息到达 Raspberry Pi 时，它将对数据进行另一次预处理，因为它对这些数据应用卡尔曼滤波器以避免噪声或失真。我们在文档中进一步解释了卡尔曼滤波器。
• 我们使用两种不同类型的板：Raspberry Pi 和 ESP32。如前所述，Raspberry Pi 充当 ESP32 和云之间的网关，放置在每个艺术品附近的 ESP32 接收来自用户的信标。有关董事会特征的更多信息，请参阅架构部分，而有关董事会角色的更深入信息，请参阅我们的文档。
• 云服务的使用：Microsoft Azure。Microsoft Azure 是一个拥挤的地方：在这里我们可以找到 IoT 中心、事件中心、我们的应用程序代码、后端，以及它的数据库和（未实现的）机器学习算法。在实际部署中，数据库包含有关艺术品的信息，当应用程序需要向用户展示艺术品的游览或详细信息时，它将对其进行查询。在我们的演示中，信息存储在后端的 DbContext 中，它还负责将它们提供给应用程序。
• MQTT的使用：物联网中用于小型传感器和移动设备的著名轻量级消息传递协议。它计划在板和网关之间使用，也用于与 Led RGB 通信。
• 我们使用蓝牙低功耗 (BLE)技术。我们需要使用 BLE 来了解用户最接近的艺术品。因此，我们真正需要实现的是邻近识别，而不是完整的室内定位。为了实现这一目标，我们还可以使用其他技术，因此我们决定在做出明确选择之前比较不同的解决方案。特别是，我们考虑了这些类型问题最常用的技术，即 BLE（我们找到了有关特定 iBeacon 协议的文档，但可以概括以下考虑）、NFC、RFID 和 GPS。合作表可在我们的文档中找到。BLE技术满足了我们所有的要求：不贵，兼容手机，范围够广，可以做近距离识别。唯一的问题是准确性，但正如所解释的，我们使用技术来缓解这个缺点（RSSI 和卡尔曼滤波器）。
• 使用发送信标的设备，在我们的例子中是智能手机。用户的智能手机启用信标广告，图板定期捕捉它们。我们的文档中提供了有关信标格式和用户跟踪的更多信息。
• 一个LED执行器，通过绿灯显示当天最受赞赏的十件艺术品。在数据处理期间，网关使用 MQTT 消息主题 /Musa/ARTWORK_ID/led 和有效负载 G_ON 将 RGB LED 打开为绿色/G_OFF 根据需要打开和关闭二极管。红色是为问题、启动阶段和状态保留的，因此它由董事会直接管理。

评价与表现

我们用不同的方法评估了用户体验和使用的技术。特别是，硬件和软件组件的质量将根据它们的特性以及整个系统的质量来衡量。但是，请记住，这是为物联网课程开发的项目，因此我们将对此进行介绍部分提供全面的分析，但不会在企业层面。

• 用户体验
  由于用户是 MuSa 的核心，因此评估的主要方面之一是用户体验。我们考虑了两种评估方法：Moment 方法和Episode 方法.关于Episode方法的问题，这是一种对整个体验提供反馈的方法，在访问结束时，用户将被要求填写一份关于他的体验的简短调查。该问卷也可以使用 AttrakDiff 来实施。对于 Moment 方法，这是一种提供有关单个时刻的反馈的方法，通过与 MuSa 的交互，我们可以了解访问者的心情（例如，如果他没有跟随我们建议的旅行可以假设他可能不喜欢它）。此外，为了这个目的，我们建议也使用像 PrEmo 这样的商业工具，它可以让 MuSa 实时了解用户的感受，但我们没有在我们的演示中实现它，因为它是一个商业工具。我们向一群人们我们的演示，并要求他们想象在博物馆中部署的完整产品。考虑到这一点，我们要求他们填写 MuSa 在定制之旅结束时向用户展示的调查。以下是收集到的答案：

 

 

 

 

1 / 5 •反馈

 

• 系统的整体评估
  软件质量由 ISO/IEC 9126-1 的一套法规和指南定义。我们使用基于标准的评估来衡量几个方面的质量，包括可理解性、文档和可移植性（我们用作模型的原始文档就是这个）。当然，我们并没有使用我们不需要的标准，所以我们制作了这个更轻量级的定制版本：MuSa Criteria。您可以在本文档中找到我们的分析结果。
• 功耗
  通过电流表进行一些测量，我们发现每个 ESP32 板在 5V 时需要大约 110mA 的电流才能工作，因此它消耗 550mW，记住我们同时使用 Wi-Fi 和 BLE，这是一个很好的值。

测量

 

• 复杂性和响应性
  我们需要我们的系统在用户访问期间能够实时响应用户，但同时我们也不想让我们的网络充斥着消息，保持低复杂性，也可以节省董事会的力量。我们需要在这两种需求之间找到平衡。因此，我们对系统进行了简要分析，并决定使用 Raspberry Pi 板作为网关（更多详细信息请参阅我们的文档）。这也影响了成本：我们希望将我们的免费计划的限制发挥到最大（我们可以发送到 Azure 的消息限制是每天 8000 条），以便我们可以尽可能少地支付。这可以是通过利用边缘计算实现：我们在网关中进行数据预处理，以汇总不同板的消息并将单个报告发送到 Azure。Raspberry 还充当一种桥梁，接收 MQTT-SN 消息并将其转换为 MQTT 消息。让我们对这个系统的复杂性和响应能力做一个简短的评估，让我们考虑以下场景：-我们有 30 个 ESP32 板，每秒发送 1 条消息-原始数据发送到 Azure：这意味着每分钟大约有 30 条消息 * 60 秒 = 1800 条消息，这意味着免费计划将在 8000 / 1800 = 4 分钟后到期。-边缘计算：不是将消息直接发送到 Azure，而是由网关收集，而是每 5 秒向云发送一个报告。所以我们每分钟有 60 / 5 = 12 条消息，这意味着免费计划将持续 8000 / 12 = 666, 66 分钟，即 11, 11 小时。所以我们每天有 5 分钟和 11 小时，优势边缘计算架构是巨大的！我们可以让一个有 30 个板的博物馆每天免费使用我们的系统（除非它保持开放超过 11 小时）。
• 最大用户数
  我们对当前硬件和技术的最大同时用户数进行了一些计算和压力测试。我们看到我们的主板使用了许多不同的技术，例如 WiFi、BLE、MQTT 和 JSON 主体。这些技术需要图书馆，而图书馆需要空间；我们的 ESP32 有 4MB 的空间，我们已经能够对它进行临时分区并为我们需要的所有空间获得足够的空间，包括代码和动态分区。但是我们有多少可用空间？没那么多。在这个空闲空间中，我们必须适应构建 JSON 的数据结构，放置从 BLE 读取的临时数据，等等。所以一些数据结构可以是静态预定义的，而另一些则存在于堆中。我们凭经验发现预定义大小的折衷方案，收集数据大约 5500 字节，网络最大消息（由于标头）更多字节，等等。有了这个值，在单次迭代的情况下，由于信标标识符/RSSI 值的最大大小为 58 字节，我们有大约 94 次迭代的空间。在我们使用信标模拟器应用程序进行压力测试期间，我们或多或少地得到了这样的结果：在 100 个信标中捕获了 93 个。让我们对此发表评论。如果我们有一个大房间，有 20 件艺术品和 20 个板子，如果每个板子最多捕捉 93 个信标，并且每个板子都捕捉到离板子很远的人的信标，那么可能我们将无法为所有访客服务，因为 93 看起来不要成为这么大的数字。我们的解决方案是什么？以较低的功率传输信标。设置信标的传输功率很容易（请参阅我们的 Android 应用程序以获取示例）。如果我们以较低的功率传输信标，则只有靠近访客的板才能捕捉到他的信标，
• 后端
  我们的后端代码质量已经过CodeCity 测试。这是一个非常简单的工具，可以让我们以一种新的方式检查最常见的软件指标，将软件系统可视化为交互式、可导航的 3D 城市。类被表示为城市中的建筑物，而包被描述为建筑物所在的地区。城市结构越好，代码质量就越高。我们在文档中提供了有关 CodeCity 的更深入的详细信息。这些是我们的结果：没有“病态”模式：没有建筑物太高，它们在景观中分布得很好。代码是模块化的和“健康的”。

代码城结果

 

• 前端
  Android 应用程序运行良好，没有出现延迟或异常行为。不幸的是，目前没有免费的工具可以从 Android 项目生成 MSE 统计信息。我们检查了软件评估的最常见指标。这些是结果：

前端评估

 

• 价格
  -硬件我们需要与博物馆展出的艺术品和单个重要作品的数量一样多的板，再加上一个用于网关的板；每一个的成本约为 10 欧元。我们还需要相同数量的 RGB LED，它们非常便宜，每个成本约为 0、50 欧元。当然，还有很多其他的解决方案可以替代 LED。最昂贵的组件是两块 Raspberry Pi 板，价格从大约 20 欧元到更多。- Cloud Azure 是一种商业产品，为小型项目提供少数免费服务。使用Microsoft 定价计算器，我们检查了用于研究目的的最便宜的解决方案。
  
  
  
  
  
  Azure IoT 中心在每天 8000 条消息之前都是免费的。利用我们的架构选择，使用主网关板作为整个传感器网络的桥梁，我们可以节省大量消息。
  Azure 数据库对于上一代 Azure 数据库（第 4 代）是免费的，只有几 GB 的空间，但您无法进行任何备份的事实是一个主要缺点。
  Azure 应用服务计划免费提供一个完整的解决方案，用于部署具有 FE 和 BE 的全栈应用程序。免费解决方案提供 1GB 存储空间、1GB RAM 和共享 CPU。请注意，以这种方式您不能让您的应用程序始终运行
  . 不幸的是，Azure 机器学习不提供任何免费计划，起价约为 4 美元/月，但同样，对于我们的最终交付，它没有实施。我们附上了一份简短的Excel 报告，以便更好地可视化所有计划。使用Azure 定价计算器可以轻松扩展此计划并评估其对成本的影响。

Musa 的工作原理 - 用户的观点

现在让我们从用户的角度来完整地解释整个系统是如何工作的！

• 首先，当参观者来到博物馆时，他必须决定是想体验 MuSa 还是只想帮助收集数据：在这两种情况下，他都需要下载 MuSa Android 应用程序。显然，对于这种解释，我们不会考虑不感兴趣的访问者。
• 之后，用户下载应用程序，填写分析调查并正式决定要使用 MuSa。

 

 

 

 

1 / 6 •欢迎页面

 

• 如果用户只想帮助收集数据，则他使用该应用程序的工作将一直持续到他的访问结束。该应用程序本身将收集有关访问者路径的数据。在游览结束时，游客将按下“结束”按钮。

 

 

 

 

1 / 2 •数据收集

 

• 如果用户希望获得 MuSa 的定制体验，则在完成初始调查后，他将收到建议的游览。然后，在他的巡演中，他将收到有关作品的信息，如作者、创作年份和其他一些细节。

 

 

 

 

1 / 2 •提供旅游

 

• 在游览结束时，将要求用户填写反馈调查，帮助评估和改进 MuSa

 

 

 

 

1 / 2 •反馈调查

 

。

• GitHub存储库
• 文档
• 领英简介：Silvia del Piano , Stefano Foti , Gianmarco Zizzo
• 幻灯片和 PDF 演示文稿
• 发布和安装说明