Ruche connectée & SigFox

Sommaire

  • Introduction
  • Cahier des charges
  • Solutions techniques mises en œuvre
    • Mesure du poids de la ruche
    • Mesure de la température et du taux d’humidité
    • Mesure de la fréquence des sons de la ruche
    • Transmission des données
    • Autonomie du système et optimisation de la consommation
    • Intégration des composants
    • Mise en œuvre d’une interface utilisateur
  • État des lieux du projet, et amélioration possibles
  • Conclusion

Introduction

A l’heure actuelle, de nombreux modèles de balances connectées pour ruches sont disponibles sur le marché. Ces balances présentent parfois des fonctionnalités supplémentaires, par exemple une station-météo intégrée, un antivol GPS, etc. Le prix de ces systèmes est assez élevé et ces modèles sont principalement destinés à des professionnels. C’est pour ces raisons que nous avons choisi de réaliser notre propre balance connectée, intégrant d’autres fonctionnalités.

Premièrement, dans la gestion d’une ruche, la température et le taux d’humidité internes sont très importants.  Ces deux grandeurs, informe directement l’apiculteur sur la santé de la colonie. Ensuite, nous avons choisi de mesurer les fréquence du bourdonnement des abeilles à l’intérieur de la ruche afin de pouvoir détecter un essaimage.

Cahier des charges

Solutions techniques mises en œuvre

Mesure du poids de la ruche

Nous avons choisi d’utiliser quatre capteurs de force en pont de Wheatstone, pouvant mesurer jusqu’à 50 Kg chacun. Ces capteurs sont connectés en parallèles, le poids maximal mesurable est donc de 200 Kg. La précision donnée par le constructeur est de ± 25 grammes. Les mesures sont effectuées par une carte programmable Arduino.

https://www.gotronic.fr/ori-capteur-de-force-50-kg-czl635-50-17601.jpg
Capteur de force

Un amplificateur – convertisseur est nécessaire pour effectuer les mesures. Le composant choisi est un amplificateur HX711. Il permet de convertir la valeur analogique de la masse mesurée en donnée numérique, transmise ensuite à la carte Arduino par communication série.

Amplificateur pour Cellule de Force HX711 - RobotShop
HX711

Il est nécessaire d’effectuer une calibration de ces capteurs, au moyen d’un code fourni par le fabriquant de l’amplificateur, utilisant une bibliothèque spécifique afin de simplifier la programmation.

Mesure de la température et du taux d’humidité

Pour mesurer la température et l’humidité à l’intérieur de la ruche, un capteur comportant ces deux fonctions est utilisé. Il s’agit d’un capteur AM2320. Ce capteur est capable de mesurer une température de -40°C à +80°C avec une précision de ±0,5°C, et un taux d’humidité allant de 0% à 99,9% avec une précision de ±3%. Il communique par un bus I2C avec la carte Arduino. Ce bus comporte deux voies, une voie d’horloge (SCL) et une voie de données (SCL). C’est un protocole standardisé très répandu dans les applications électroniques. Concernant la programmation, l’utilisation d’une bibliothèque fournie par Adafruit inclus toutes les fonctions nécessaires à la programmation.

https://www.gotronic.fr/ori-capteur-de-t-et-d-humidite-am2320-27959.jpg
AM2320

Mesure de la fréquence des sons de la ruche

               La fréquence des sons produits par les abeilles ne s’obtient pas directement par lecture de la valeur d’un capteur. Le capteur utilisé est un micro à électret amplifié ADA1063. Il dispose d’une sortie analogique. Pour obtenir la valeur de la fréquence, il est nécessaire d’effectuer une FFT (Fast Fourier Transform) sur un certain nombre d’échantillons de la sortie analogique du capteur. On choisit 128 échantillons (limite maximale pour Arduino) et une fréquence d’échantillonnage de 1212Hz, nécessaire pour mesurer des fréquences jusqu’à 600Hz. Le calcul de cette FFT est effectué par une bibliothèque Arduino (arduinoFFT). Ce calcul à ensuite été testé en utilisant un générateur de fréquences sonores sur smartphone. En faisant varier le générateur entre 50Hz et 600Hz, toutes les mesures obtenues sont justes, avec une tolérance de ± 4Hz. Cette plage de fréquences mesurables est donc tout à fait en adéquation avec la plage de fréquence des sons des abeilles, comme indiqué dans Abeille & Cie N°165.

ADA1063

Transmission des données

Pour transmettre les données issues de la ruche à l’apiculteur, nous avons choisi d’utiliser le réseau Sigfox. C’est un réseau de communication basse puissance (868Mhz) qui présente beaucoup d’avantages.

  • Avantages :
    • Basse puissance (non perturbant pour les abeilles)
    • Basse consommation
    • Couverture réseau très importante en France
    • 14 émissions par jour
    • Bidirectionnel (Émission / Réception)
  • Inconvénients :
    • Abonnement nécessaire (3€/an selon Sigfox).
    • Transmissions « lentes » en raison de la basse fréquence.

Plusieurs modèles de modules Sigfox existent.  Pour notre application, nous avons choisi d’utiliser une carte programmable Arduino MKR FOX 1200 qui intègre un moule de communication Sigfox. Cette carte est particulièrement adaptée au développement de ce type d’application, en raison de sa faible consommation, de son encombrement réduit, et de son coût.

Carte Arduino MKR FOX 1200 ABX00014 Arduino - Cartes MKR | GO TRONIC
Arduino MKR FOX 1200

Un abonnement d’un an au service Sigfox est inclus avec la carte programmable, qui s’active automatiquement dès le troisième message transmis sur Sigfox. Il sera donc nécessaire de renouveler par la suite cet abonnement.

Arduino fourni une bibliothèque Sigfox, proposant des fonctions simples pour envoyer des messages sur le réseau Sigfox. Le programme final effectue donc les mesures de poids, de température, de taux d’humidité, calcul la fréquence du son produits par les abeilles, et transmet ces données actualisées toutes les 20 minutes.

Alimentation, autonomie du système et optimisation de la consommation

Dans le but de diminuer la consommation du système, et donc d’augmenter son autonomie, plusieurs solutions sont mises en œuvre. D’une part, la programmation sous Arduino permet de réduire la consommation de deux façons. Premièrement, la carte utilisée est capable d’être « endormie » lorsqu’elle n’est pas utilisée. De la même façon, l’amplificateur HX711 peut lui aussi être mis en veille lorsqu’il n’est pas utilisé, grâce à sa bibliothèque. Passer cet amplificateur en veille réduit la consommation de 20mA.

Ensuite, il est nécessaire d’utiliser un régulateur de tension linéaire 5V, pour abaisser la tension de la batterie 12V en 5V. Dans un premier temps, nous avons utilisé un régulateur LM1085, qui consommé 10mA à vide. Nous l’avons finalement remplacé par un régulateur LM78L05, dans un boitier TO-92. La consommation à vide mesurée de ce régulateur est de 3,2mA, ce qui a permit de réduire encore la consommation de 6,8mA.

Des mesures de consommation en fonctionnement typique du système ont été effectuées. Ce fonctionnement est décomposé en 3 phases : « Sleep » lorsque la carte Arduino et l’amplificateur HX711 sont en veille entre deux transmissions, « Mesure » lorsque la carte Arduino effectue les mesures des différents capteurs et calcule la fréquence et « Emission », lorsque les données sont émises sur Sigfox. Pour un cycle, la phase « Mesures » dure 5 secondes, et la phase Emission dure 10 secondes. La phase « Sleep » dure tout le reste du temps, soit : 20min – 5s – 10s = 1195s.

Les consommations dans ces différentes phases, sont les suivantes :

  • Sleep : 16 mA (pendant 1195s)
  • Mesure : 44 mA (pendant 5s)
  • Emission : 59 mA (pendant 10s)

Afin de réduire encore ces consommations, la led Power implantée sur la carte Arduino, et allumée en permanence, a été dessoudée. A l’aide du schéma électronique fourni par Arduino, nous avions calculé que cette led consommait environ 10mA. Ce calcul a été confirmé par de nouvelles mesures de consommation. Supprimer cette led permet d’abaisser la consommation de 9mA. On obtient donc les mesures suivantes :

  • Sleep : 7 mA (pendant 1195s)
  • Mesure : 35 mA (pendant 5s)
  • Emission : 50 mA (pendant 10s)

Sur une heure, cela correspond à une consommation moyenne de 7,5mA/h soit 0,2A/h par jour.

Concernant la batterie, nous avons utilisé une batterie au plomb, que nous avions en stock à l’IUT. C’est une batterie 12V, 9Ah. Avec cette batterie, l’autonomie maximale du système est donc de 45 jours. Néanmoins le principal inconvénient de cette batterie est son encombrement. Elle mesure 15,1cm x 10,2cm x 6,5cm, et pèse 2,7Kg.

Intégration des composants

Afin de connecter les différents composants électroniques entre eux, nous avons réalisé un circuit imprimé dans le laboratoire d’électronique de l’IUT. Ce circuit permet d’accueillir le régulateur de tension, la carte Arduino et l’amplificateur HX711. Des borniers y sont aussi implantés, permettant de faciliter la connexion de l’alimentation, des capteurs de force, le micro et le capteur de température et d’humidité. Ce circuit imprimé ainsi que la batterie, sont placés dans un coffret plastique d’électricien.

Boitier électronique

Les étudiants en Génie Mécanique et Productique, ont réalisé le support de ruche intégrant les quatre capteurs de force.

Support de pesée

Mise en œuvre d’une interface utilisateur

               Une interface utilisateur a été mise en œuvre, afin de faciliter la lecture et le suivi des données.  Elle a été réalisée en utilisant Node Red. Elle est composée de trois onglets :

  • Synoptique : Dernières mesures, heure de la dernière transmission, graphique de l’évolution du poids sur 24h, météo en temps réel à l’emplacement de la balance.
  • Graphiques : Graphiques de l’évolution du poids sur 24h et sur 7 jours, de la fréquence sur 24h, de la température et du taux d’humidité sur 24h.
  • Historique : Tableau regroupant les données des 1000 dernières transmissions.

Pour ce premier prototype, nous avons choisi d’héberger cette interface sur un Raspberry Pi, en réseau local. Cela signifie qu’il est uniquement possible d’accéder à l’interface lorsque l’on est connecté sur le même réseau que le Raspberry Pi. Nous avons réalisé ce choix afin de ne pas être dépendants d’un service d’hébergement de serveur Web. Il est possible d’associer plusieurs balances à la même interface.

État des lieux du projet

Un grand nombre des fonctions définies par le cahier des charges ont pu être mises en œuvre. Premièrement, l’acquisition des données, que ce soit les données issues de la ruche, ou bien les données météorologiques récupérées sur Internet les fonctions attendues ont été mise en place. Ensuite, la transmission des données est bien autonome en utilisant le réseau Sigfox, et est régulier toutes les 20min. Néanmoins, nous n’avons pas encore mis en marche une transmission de données événementielles. L’interface utilisateur n’est pas sur un site Web et ne nécessite donc pas de système de connexion par mot de passe. De plus, les données sont actualisées à chaque nouvelle transmission, et il est possible de suivre l’évolution chronologique des différentes grandeurs. L’autonomie du système est inférieure à celle fixée par le cahier des charges, et nous n’avons pas encore pu tenter d’implanter des cellules photovoltaïques. Pour finir, l’objectif de coût du projet est respecté : le coût de tous les composants (support exclu) permettant de réaliser cette balance est d’environ 220€.

Conclusion

Pour conclure, ce projet nous a permis tout d’abord de découvrir ou d’approfondir nos connaissances en matière d’apiculture, notamment l’importance de la température et du taux d’humidité interne à la ruche, ainsi que la « signification » des signaux sonores d’une colonie d’abeilles. Ces informations permettent à l’apiculteur, amateur ou professionnel, de mieux suivre et soigner ses colonies.

Les principales fonctions du cahier des charges ont été mises en œuvre. La balance est placée sous une ruche depuis maintenant deux semaines. Les mesures effectuées sont toujours cohérentes avec l’environnement et les conditions météorologiques. Néanmoins, il est nécessaire d’effectuer des tests sur une plus longue période.

De nombreuses améliorations peuvent tout de même déjà être envisagées, en particulier au sujet de l’autonomie du système, et de son encombrement. Parvenir à rendre accessible l’interface utilisateur depuis le Web est aussi un point à travailler.

Simon RAPP

Loyna WALTER

Hugo KLEIN

Anthony LITTERST