Pilbifarmer

De fablab
Aller à : navigation, rechercher
PilbiFarmer
Boitier1.jpg
Cultiver votre ferme

Présentation du Projet

Lien vers le projet

https://github.com/ygouzerh/pilbifarmer

Membres de l'équipe

  • Yassir IDHBI
  • Omar LARAQUI
  • Ali HAJJI
  • Yohan GOUZERH
  • Bandian CONDE

Problématique

“821 millions de personnes souffrent de la faim dans le monde, et 150 Millions d’enfant accusent des retards de croissance dû à la malnutrition” d’après un communiqué de l’OMS (Organisation Mondiale de la Santé) le 22 septembre 2018. (https://www.who.int/fr/news-room/detail/11-09-2018-global-hunger-continues-to-rise---new-un-report-says).

Nous aurions pu partir sur un énième projet d’objet connecté, utilisable par quelque occidentaux. Seulement, nous pensons qu’en tant qu’ingénieur, il est de notre devoir de tenter de résoudre des défis de grande envergure, avec les moyens à notre portée. Nous sommes ingénieurs en informatique, et nous souhaitons donc produire de la nourriture grâce à l’informatique.

Nous proposons ici un début de solution, permettant de créer facilement et avec des moyens limités, un environnement de culture en intérieur. Cet environnement permet de s’affranchir des conditions climatiques ainsi que du besoin de terres cultivables, défis centraux dans le problème de la faim dans le monde. Cette solution permet ainsi de reproduire n’importe quel environnement de culture pour coller au plus prêt aux besoins de n’importe quelle plante.


Scénario d'utilisation

Notre solution doit permettre à un fermier de récupérer des données essentielles sur une plante qu’il est en train de cultiver, d’effectuer des actions manuelles ou programmées sur celle-ci (arrosage, allumage d’une lampe de croissance,....)

Contraintes du Projet

La contrainte principale ici est la scalabilité. Il doit être possible d’augmenter facilement le nombre de cultures, afin de produire à grande échelle.

Etant donné que nous sommes en intérieur, nous formons l’hypothèse que la structure est alimentée en électricité, nous n’avons pas besoin d’une alimentation électrique spécifique par plante. Il est facile d’être relié à une prise électrique, mais il est sûrement difficile pour chaque système de chaque plante d’être relié au réseau informatique. Il est donc nécessaire d’utiliser un protocole de communication sans-fil permettant de récupérer et d’envoyer des données vers un hub central, connecté au réseau.

Nous devons pouvoir envoyer des commandes depuis l’extérieur, vers la ferme.

Technologies et matériel

Matériel

  • Raspberry Pi 3 model B
  • Arduino UNO
  • HC-05 (module bluetooth pour l’arduino)
  • NeoPixel (leds représentant une lampe de croissance)
  • Pompe péristaltique (Pompe doseuse)
  • Driver Moteur (pour piloter la pompe)
  • Capteur température-humidité du sol-lumière

Technologies

Cloud

  • Iot Hub
  • Stream Analytics
  • Power BI
  • App Center
  • SQL Database

Web

  • AngularJS
  • NodeJS

Architecture

Principaux défis : la communication internet -> réseaux privés

Ici, nous souhaitons pouvoir envoyer des commandes depuis une interface web (serveur sur internet) à l’appareil contrôlant notre plante.

Dans une architecture normale, c’est la machine située dans le réseau privé qui se connecte au serveur. En ayant ouvert cette connexion, il est possible ensuite pour le serveur de lui envoyer les données.

Ici, nous voulons que ce soit l’inverse, qu’un serveur extérieur au réseau puisse envoyer des commandes à notre appareil.

Avec les réseaux IPv4 actuels, il est très difficile de réaliser cela, étant donné le nombre de barrières présentes, comme la NAT, ou bien le firewall.

Les moyens habituels pour contourner ces barrières sont les suivants : utilisation du mécanisme d'adresses routables IPv6 (malheureusement non activé dans la plupart des réseaux privés actuels à des fins de sécurité), utilisation d’un tunnel VPN, mise en place de règles de DNAT,....

Cependant, nous ne souhaitons pas avoir à modifier le réseau existant sur lequel se baserait notre solution, et à avoir une solution simple à mettre en oeuvre.

Le mécanisme que nous avons utilisé est le suivant : l’utilisation d’un mécanisme de Publish/Subscribe, par le biais du service Iot Hub de Microsoft Azure et au protocole de couche applicative MQTT.

Dans ce modèle, le serveur web va “publier” un message dans un nouveau “topic” (voir cela comme une file FIFO) sur l’IoT Hub. Les clients qui ont “souscrit” à ce topic, vont périodiquement initier une connexion avec l’IoT Hub, afin de récupérer les derniers messages envoyés.

Architecture de Iot Hub


Dans ce modèle, au lieu que ce soit le serveur web qui envoi les données aux clients, c’est l’appareil qui va périodiquement vérifier si de nouvelles données sont disponibles. De plus, outre le fait aussi de n’utiliser qu’un protocole de couche applicative utilisant dans notre cas le port très souvent ouvert 443 (basé sur https), ce modèle est asynchrone, et permet ainsi de s’abstraire des problèmes d’horloge commune et de connexion pré-établie.

Architecture du Projet

Architecture Distribuée
Architecture Distribuée

Dans cette architecture, trois parties sont distinguables : La partie électronique, interfaçage avec le monde physique, géré par des automates, qui vont récupérer les données des capteurs et activer les actionneurs pour chaque plante. La partie Cloud, “cerveau” de la solution, qui s’occupe de tous les traitements, d’envoyer les commandes, et de l'interface avec l’utilisateur. La partie Raspberry Pi. C’est la seule partie du réseau privé qui a un accès internet et qui peut ainsi communiquer avec le Cloud. Elle s’occupe de faire le lien entre les Arduinos (communications bluetooth) et le Cloud (protocole MQTT).

Récupération des données : Après récupération des données à partir des capteurs de chaque plante, l’arduino envoie les données vers la Raspberry en utilisant le module Bluetooth HC-05. Dès que cette dernière reçoit les données, elle les renvoie au service cloud IoT Hub.

Plusieurs services fournis par Azure Cloud nous permettent de faire des graphes et schémas afin d’aider le fermier à monitorer son exploitation et ainsi prendre les bonnes décisions.

Exécution des commandes : Les commandes à exécuter sont récupérées grâce au mécanisme de Publish/Subscribe (Voir partie Envoi des commandes Cloud -> Raspberry Pi), et envoyées à la bonne arduino, qui va ensuite les exécuter.

Interface Homme Machine : site web

L'interface web permet à l'utilisateur de gérer la totalité de ses fermes connectées. Quand une ferme est sélectionnée, la liste des plantes s'affiche ce qui va permettre à l'utilisateur de voir l'état des capteurs pour chaque plante, programmer des périodes d'arrosage ou de lumière, mais également contrôler manuellement le moteur et la lumière UV pour chaque plante et de les mettre en marche ou de les éteindre quand il le souhaite.

Application Web

Ce qui est fait derrière les rideaux?

Une base de données a été mise en place pour stocker les plantes par ferme pour qu’on puisse par la suite y accéder par la page web. La base de données stocke également le mode d’arrosage ou de lumière choisi par l’utilisateur (automatique ou manuel) pour chaque plante, ainsi que les commandes programmés par l’utilisateur en mode automatique. Le back-end de l’application Web est connectée avec Azure IoT Hub pour permettre l’envoi des commandes à exécuter à la bonne Raspberry.

Application Web

Envoi des commandes Cloud -> Raspberry Pi

Architecture distribuée
Architecture distribuée

Les commandes automatisées sont stockées dans une base de données avec la date d'exécution, ainsi que la durée de l’action, et l’identifiant de la plante. Il est ainsi possible par exemple de programmer l’allumage de la lumière le jeudi 24 janvier à 15h20 durant 50 secondes.

Une application en Node.js (ici sur le même serveur web dans des soucis de simplicité, mais peut très bien être utilisée en mode Function-as-a-Service) se charge toutes les 5 minutes de vérifier quelles commandes sont programmées à cet horaire, avec un intervalle de 1 minute (pas de contraintes importantes de temps réel) afin de prendre en compte le décalage d’horloge.

Si le mode automatique est activé pour la plante, alors l’application va envoyer la commande à l’IoT Hub, à destination de la bonne Raspberry ( récupération de la correspondance entre l’identifiant de la plante et celui de la Raspberry dans la base de données).

Pour lancer une commande manuelle, le serveur web envoie directement la commande à l’IoT Hub en utilisant le protocole MQTT.

Les commandes sont publiées sur l’IoT Hub dans un topic spécifique à chaque Raspberry, qui se comporte à l’instar d’une file FIFO. De l’autre côté, la Raspberry Pi va se connecter à l’IoT Hub, s’abonner à son topic, et ainsi récupérer les commandes une à une, suivant l’ordre d’émission.

De l’autre côté, la Raspberry Pi va se connecter à l’IoT Hub, s’abonner à son topic, et ainsi récupérer les commandes une à une, suivant l’ordre d’émission.

Le format des commandes utilisé est le JSON :

               var payload = {
                    planteId: planteId,
                    action: {
                        name: actionName,
                        mode: {
                            name: modeName,
                            params: params
                      }
                  }
              }

PlanteID est l’adresse bluetooth de l’Arduino s’occupant de la plante, action.name est le nom de l’action à effecuter (light => allumage de la lampe, water => arrosage de la lampe), action.mode.name est le mode utilisé (On/Off/Period), et params est un objet json contenant des paramètres supplémentaires. Par exemple, {“time”: 10} permet de spécifier une durée dans le cas où le mode utilisé est period (effectuer une action sur une certaine periode).

Par exemple, si nous avons :

              var payload = {
                  planteId: "00:14:03:06:8E:56",
                  action: {
                      name: "light",
                      mode: {
                          name: "period",
                          params: {
                              "time": 10
                          }
                      }
                  }
              }

Cette commande allumera la lumière de la plante 00:14:03:06:8E:56 pour une période de 10 secondes.

Envoi des commandes Raspberry Pi -> Arduino et exécution

Après chaque commande reçue du cloud, la Raspberry déclenche l'exécution d’un script permettant d’envoyer cette commande à l’Arduino sous forme d’un code en nombre entier sur lequel l’Arduino effectue un traitement particulier pour reconnaître l’action à réaliser, le mode, et la durée de l’action en cas d’un mode programmé. Le code Arduino dispose d’un bloc permettant de vérifier de façon périodique la réception d’une commande de la Raspberry. A la réception du message par l’Arduino, le traitement du nombre entier renvoie l’action appropriée et l'exécute par la suite.

Remontées des données des capteurs

Architecture cloud
Architecture cloud

Les capteurs mis sur le board de l’Arduino auront à envoyer périodiquement des données vers le cloud, nous avons donc attribué à chacune des Arduinos un identifiant unique qui est concrètement l’adresse mac relative à son module Bluetooth.

La Raspberry possède un dictionnaire des différentes Arduinos dans la même serre. Tout d’abord, la Raspberry crée une connexion avec Iot Hub, interroge les Arduinos sur la même serre par intervalle de temps. Elles lui renvoient la température ambiante, l’humidité du sol, et le niveau de lumière projeté sur la plante, la Raspberry encapsule ces données avec l’identifiant de la plante et les envoient vers IoT Hub, qui n’est concrètement qu’un pipeline qui nous servira comme entrée au Stream Analytics job.

En sortie, nous avons utilisé Power Bi pour l’affichage des données, en spécifiant la connexion à utiliser, le nom du dataset, la table à alimenter ainsi que le type des données reçues qui sont dans notre cas des documents JSON. Il ne reste plus qu’à lier les entrées aux sorties à l’aide d’une requête qui va dispatcher les entrées sur les différents rapports sur Power Bi de telle sorte que chaque plante aura son propre rapport visuel.

StreamAnalytics

Une fois le Stream Analytics Job démarré et que Iot Hub se voit recevoir des données, les données vont être automatiquement insérées sur Power Bi.

StreamAnalytics

Nous avons pensé qu’il puisse être possible que l’utilisateur ne soit pas familier avec la gestion des rapports, et donc pour lui faciliter la tâche, il n’aura qu’à spécifier la plante sur l’application web pour avoir un visuel intégré du rapport de la plante.

StreamAnalytics

Évolutions possibles du projet :

Fonctionnalités supplémentaires possibles:

  • Remplacement de la lampe par une vrai lampe de croissance
  • Récupération de données sur la qualité du sol
  • Récupération du niveau d’eau et remplissage automatique du réservoir
  • Système de refroidissement de l’air ambiant
  • Hydroponie

Matériel

Décentralisation

L’architecture de hub central et de communication bluetooth peut-être remplacée par une architecture décentralisée, en utilisant une Raspberry Pi Zero W par plante seulement. Cette nouvelle Raspberry permettrait en quelque sorte de fusionner les fonctions de notre Raspberry Pi centrale et notre Arduino. Cette carte à 10 euros, permet à moindre de coûts de contrôler directement la partie électronique de notre solution, grâce à la possibilité de soudure de pin GPIO, tout en étant reliée directement à l’IoT Hub, sans passer par un hub intermédiaire. Cela serait une solution économique, plus facile à configurer, et plus scalable (suppression de la Raspberry centrale qui était le point-of-failure principal).

Cloud

Les solutions fournies par Microsoft peuvent vite devenir très chères, et la question peut se poser de les remplacer par des solutions maisons.

  • Remplacement d’IoT Hub :

Pour l’envoi des commandes, l’IoT Hub peut être remplacé par un broker maison Publish / Subscribe comme Faye.js (https://faye.jcoglan.com/) pour la facilité, ou bien Mosquitto (https://mosquitto.org/) pour rester sur du MQTT.

  • Remplacement de Streams Analytics et de PowerBi:

Pour remplacer la solution de streaming pour la remontée des données nous pouvons utiliser ici une solution maison Apache Kafka + Graphana.

  • Remplacement de Azure App Center:

Pour l’application web, une solution web micro-service en FaaS (Azure Functions) + pages statiques permettrait de diminuer les coûts.

Références

Documentation utilisée pour l’envoi des données des capteurs : https://docs.microsoft.com/fr-fr/azure/iot-hub/quickstart-send-telemetry-node

Documentation utilisée pour l’envoi des commandes : https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-node-node-c2d