« Suivi des ruches » : différence entre les versions

De Kernel Fablab Lannion
mAucun résumé des modifications
 
(47 versions intermédiaires par 2 utilisateurs non affichées)
Ligne 4 : Ligne 4 :
= Présentation =
= Présentation =


Le projet Bzzz (Bee Zen Cube) est un projet de suivi de ruches pour une apiculture plus anticipative, il a pour but de proposer gratuitement à tout apiculteur amateur les plans d'un kit de supervision de son rucher (mono-ruche voire évoluer vers le multi-ruche, si le prix des émetteurs LoRa reste élevé). Le projet Bzzz suit l'évolution de la santé de la ruche à distance, principalement par la mesure des variations de poids, la température locale et donner l'alerte en cas d'essaimage ou surtout, de la préparation de l'essaimage. On fait tout cela pour éviter de multiples déplacements de l'apiculteur.
Le projet Bzzz (Bee Zen Cube) est un projet de suivi de ruches pour une apiculture plus anticipative, il a pour but de proposer gratuitement à tout apiculteur amateur les plans d'un kit de supervision de son rucher (châssis de mesure autonome, et si le prix des émetteurs LoRa reste élevé réaliser une station d'émission qui centraliserait plusieurs châssis secondaires). Le projet Bzzz suit l'évolution de la santé de la ruche à distance, principalement par la mesure des variations de poids, la température locale et donner l'alerte en cas d'essaimage ou surtout, de la préparation de l'essaimage. On fait tout cela pour éviter de multiples déplacements de l'apiculteur.


Le projet Bzzz est un projet [http://fr.wikipedia.org/wiki/Open_source Open-source] et [http://en.wikipedia.org/wiki/Open-source_hardware Open-hardware]
Le projet Bzzz est un projet [http://fr.wikipedia.org/wiki/Open_source Open-source] et [http://en.wikipedia.org/wiki/Open-source_hardware Open-hardware]


Ce projet fédère plusieurs bénévoles au sein du fablab et est suivi par les médias locaux ainsi que par des apiculteurs d'autres régions (volontaire pour prototypage notamment). Plusieurs apiculteurs ont aussi fait le déplacement au sein du FabLab de Lannion pour venir découvrir ce projet et se porter volontaire pour une période de béta-test dés que la solution sera pleinement fonctionnelle:<br />
Ce projet fédère plusieurs bénévoles au sein du fablab et est suivi par les médias locaux ainsi que par des apiculteurs d'autres régions (volontaire pour prototypage notamment). Plusieurs apiculteurs ont aussi fait le déplacement au sein du FabLab de Lannion pour venir découvrir ce projet et se porter volontaire pour une période de béta-test dés que la solution sera pleinement fonctionnelle.<br />


Les évolutions possibles sont notées dans la partie [[Suivi_des_ruches#Todo_liste|ToDoList]] (amélioration, bug à corriger, ajout de capteurs, multi-ruche, etc...).<br /><br />
<br />
Les recherches effectuées n'ont montrées aucune contre indication par rapport aux brevets déjà existants. <br />


= Participants =
= Participants =
Ligne 17 : Ligne 16 :
<div class="mw-collapsible-content">
<div class="mw-collapsible-content">
* Bernard Arzur
* Bernard Arzur
* Frédéric Carré
* David Blaisonneau
* Thierry Houdouin
* Thierry Houdouin
* Morgan Richomme
* Jérôme Labidurie
* Jérôme Labidurie
* David Blaisonneau
* Tangi Lavanant
* Tangi Lavanant
* François-Xavier Potel
* Morgan Richomme
</div>
</div>
</div>
= Chassis / Capteurs =


= Chassis / Capteurs =
<div class="toccolours mw-collapsible mw-collapsed">
<div class="mw-collapsible-content">
Porteur: Bernard
Porteur: Bernard


== Module Chassis ==
== Module Chassis ==
===Demi-Chassis (abandonné)===
===Demi-Chassis (abandonné)===
* Une seule jauge de contrainte par capteur/demi-chassis(diminution du prix)  
* Une seule jauge de contrainte (50 kg) par capteur/demi-chassis(diminution du prix)  
* On accède au paramètre de variation du poids
* On accède au paramètre de variation du poids
* La valeur absolue du poids de la ruche n'est pas connue
* La valeur absolue du poids de la ruche n'est pas connue
* On peut voir le shield W6Labs associé à un Arduino UNO et un HX711.
[[File:DemiRuche.jpeg|400px]]
[[File:DemiRuche.jpeg|400px]]
[[Fichier:DSCF1946.jpg|400px]]
[[Fichier:DSCF1946.jpg|400px]]


==2 Demi-Chassis (abandonné) ==
===2 Demi-Chassis (abandonné) ===
*Le support associé est remplacé par un 2éme demi-chassis
*Le support associé est remplacé par un 2éme demi-chassis
* Le poids exact est connu par la somme des 2 valeurs issues des 2 capteurs
* Le poids exact est connu par la somme des 2 valeurs issues des 2 capteurs
* Le coût est un peu plus élevé  
* Le coût est un peu plus élevé  
</div>




==Chassis autonome==
 
Cette solution, simple, a été rendue possible par la forte baisse du prix des composants (LoRa, jauges, ...) et aussi par la réduction drastique de la consommation du Lopy4 en mode veille (abandon de l'Arduino).
===Chassis autonome===
* Quatre jauges de contrainte par chassis
 
* On accède aux paramètres de poids dans l'absolu, de la variation du poids, et aussi du centre de gravité (placement de l'essaim dans la ruche et des cadres remplis)
Cette solution, simple, a été rendue possible par la forte baisse du prix des composants (LoRa, jauges, ...) et aussi par la réduction drastique de la consommation du Lopy4 en mode veille (=> abandon de l'Arduino associé à une carte économiseur).
* La valeur absolue du poids de la ruche n'est pas connue
* Quatre jauges de contrainte par châssis.
* On accède aux paramètres de poids dans l'absolu, de la variation du poids, et aussi du centre de gravité (placement de l'essaim dans la ruche et des cadres remplis).
* La valeur absolue du poids de la ruche est connue, mais il ne faut pas oublier la variation due à l'humidité du bois (peut monter à 15% du poids du bois de la ruche) et la correction nécessaire pour compenser les écarts thermiques. Comme on mesure des microvolts, le moindre effet de couple thermo-électrique est largement amplifié : éviter soudures, connectiques...
 
<big>Cahier des Charges :</big>
 
-système autonome pendant une année entière
 
-l'ensemble des composants doit fonctionner entre -30°C et +70°C
 
-une mesure toutes les 10 minutes, y compris pendant la nuit (éviter le vol de ruche), soit ~50 000 mesures/an
 
-précision souhaitée : 10 grammes (100 abeilles) pour une masse maximum de 100 kg
 
-compatibilité avec la norme LoRa (durées et fréquences d'émission)
 
-coût inférieur à 100 €
 
-pas de câbles ni fils visibles
 
-hauteur maximum 30 mm
 
-gestion simple


= Mesure du poids =
= Mesure du poids =
<div class="toccolours mw-collapsible mw-collapsed">
 
<div class="mw-collapsible-content">
*Il est connu à 10 grammes près, sur une plage de  0 à 100 kg, avec des jauges de 20 kg. Si on vise au-delà de 80 kg (4*20kg), il existe des jauges de 50 kg beaucoup plus coûteuses et forcément un peu moins précises.
*Il est connu à 10 grammes près, sur un plage de  0 à 100 Kg.
*Mesuré par une jauge de contrainte résistive connectée en un pont de Wheatstone [https://fr.wikipedia.org/wiki/Jauge_de_d%C3%A9formation]
*Mesuré par une jauge de contrainte résistive connectée en un pont de Wheatstone [https://fr.wikipedia.org/wiki/Jauge_de_d%C3%A9formation]
*Numérisation de la mesure (0-10mV) par un module HX711 (convertisseur analogique/numérique à 24 bits de précision)
*Numérisation de la mesure (0-10mV) par un module HX711 (convertisseur analogique/numérique à 24 bits de précision)
*Le module HX711 est connecté au plus près de la jauge, pour éviter les interférences électromagnétiques et les effets thermiques
*Le module HX711 est connecté au plus près de la jauge, pour éviter les interférences électromagnétiques et les effets thermiques (thermo-couple). Les effets thermiques sur la résistance de mesure sont en principe compensés par l'utilisation d'une autre résistance montée en orthogonal sur la jauge.
*Le module HX711 est connecté au module d'émission IoT, qui peut donc en recevoir plusieurs (optimisation des coûts)
*Le module HX711 est connecté au module d'émission IoT, qui peut donc en recevoir plusieurs. Avec Lopy, il a été impossible d'utiliser un canal de données commun (DOUT), alors qu'avec Arduino, cela fonctionne. Comme on dispose d'assez d'entrées/sorties, la question se résout facilement : chaque HX prend une entrée (DOUT) et une sortie (SCK).
</div>


= Arrachage / Vol =
= Arrachage / Vol =
Alarme au bout de 10 minutes maximum, sur variation de poids brutale
Alarme au bout de 10 minutes maximum, sur variation de poids brutale
Alarme instantanée sur capteur de contact, optionnel
Alarme instantanée sur capteur de contact, optionnel


= Châssis autonome (Mesure et Émission) =
= Châssis autonome (Mesure et Émission) =
<div class="toccolours mw-collapsible mw-collapsed">
 
<div class="mw-collapsible-content">
==Boitier==
==Boitier==
L'idée, au départ, était d'avoir un boîtier avec émetteur RF qui collecte plusieurs balances sans émetteur, voire sans batterie, vu le prix élevé des composants à ce moment...
*Il doit être étanche, résistant car il restera à l'extérieur plusieurs années.
*Il doit être étanche, résistant car il restera à l'extérieur plusieurs années.
*Il doit donc être de catégorie IP64 au moins. Nous avons choisi IP65 pour une meilleure fiabilité à long terme.
*Il doit donc être de catégorie IP64 au moins. Nous avons choisi IP65 pour une meilleure fiabilité à long terme.
Ligne 75 : Ligne 98 :
** Antenne
** Antenne


*Nous avons donc choisi un boîtier "Raccordement Fibre Optique" qui permet d'ajouter facilement des entrées-sorties
*Nous avons donc choisi un boîtier "Raccordement Fibre Optique" qui permet d'ajouter facilement des entrées-sorties -> abandon, on ne veut plus de fils/cables autour de la ruche, pour des raisons de sécurité et de fiabilité.
==Alimentation==
 
==Alimentation solution Arduino==
* Batterie de 4 éléments de 2800mAh
* Batterie de 4 éléments de 2800mAh
* La carte économiseur (basée sur 3 relais basse consommation Reed et un Ampli-Op LM324)  permet de diviser la consommation par 100 :
* La carte économiseur (basée sur 3 relais basse consommation Reed et un Ampli-Op LM324)  permet de diviser la consommation par 100 :
** 1 mA en consommation moyenne > 6 mois d'autonomie prévue
** 1 mA en consommation moyenne > 6 mois d'autonomie prévue
** 0.6mA au repos
** 0.6mA au repos
** 120mA en émission (qq secondes toutes les 10 min)  
** 120mA en émission (qq secondes toutes les 10 min)
Cependant, l'autonomie obtenue est insuffisante et la carte économiseur revient cher (>20€).
 
==Alimentation solution Lopy==
 
Solution retenue : 3 Batteries de 3000mAh
 
La carte Lopy4 (pas toutes les versions, malheureusement!) dispose d'une mise en veille profonde : elle coupe l'alimentation du processeur principal, et la consommation chute à une valeur très faible, entre 20 µA et 200µA. Cette consommation varie à la hausse si on utilise la carte Expansion Board pour connecter le Lopy4.
On essaiera de s'affranchir de cette carte, à cause de son prix (~20€), de sa conso (due entre autre autres au pont diviseur pour mesurer la tension batterie) et des limitations du chargeur de batterie (500 mA max).
On la remplace par un circuit de charge, un pont diviseur de haute impédance et on soude directement le Lopy sur le circuit imprimé.
 
Pour se maintenir en veille, les HX711 ont besoin d'être polarisés en tension sur la broche SCK, il faut monter des résistances de pull-up d'environ 1 MOhm entre SCK et +3.3V. Sinon, chaque HX711 pourrait rajouter 8 mA à la consommation de veille.


==Arduino Lora==
*Le module HX711 émet un signal numérique sur 5V
 
* Il est connecté sur les broches 0-1 de l'arduino
** 10 000 heures(~une année) au repos représentent donc, pour 100µA ->  1000 mAh
* On peut mettre 4 HX711 sur l'arduino en l'état actuel, a voir si on peut multiplexer les capteurs sur 2 broches
 
* Le module lora utilise les pin 10-11-12-13
** Lorsque Lopy4 se réveille, il doit recompiler son code : ça prend entre 2,5 s (70 lignes) et 3.5 s (250 lignes) selon la complexité du programme et l'appel aux différentes bibliothèques. Puis il effectue la mesure de poids et envoie le paquet LoRa.
 
La durée de transmission LoRa est minimisée en configuration RAW : on transmet le paquet en clair vers un récepteur calé sur la même fréquence. Le type de trame est le suivant : "labeld4212dbzz3d284d452d406d233d", soit 32 à 40 octets, label permet d'identifier que c'est notre trame, d est le délimiteur avec le champ suivant qui est la tension batterie, bzz3 est le nom de la ruche tel qu'on l'a défini sur TTN par exemple, puis les quatre poids en grammes. La somme des 4 donne le poids total et sa position en 2D.
 
On peut transmettre en APB vers une GateWay de TTN par exemple. On envoie d'abord plusieurs champs que TTN aura calculé au préalable : un champ de 8 octets pour l'identité d'émetteur, un champ de 32 octets pour l'application et un champ de 32 octets pour l'identité du réseau. Et puis, on envoie notre trame sans le champ label, qui est remplacé par les champs TTN. On devine que ce deuxième mode APB sera un peu plus lent et plus gourmand en énergie et bande passante(70 octets de plus) et pas forcément compatible avec les critères LoRa.
 
Le mode OTAA n'a pas été considéré, il nécessite régulièrement un échange bidirectionnel avec la GateWay de TTN pour maintenir notre émetteur sur le réseau TTN, entraînant une surconsommation d'énergie.
 
Le courant absorbé varie durant le cycle entre 40 mA (compilation), 140 mA (mesure) et 200 mA (envoi paquet LoRa), avec une moyenne à 120 mA pour un cycle de 14s. Pour 5 s, l'intensité moyenne devrait être plus basse (à vérifier), puisque le % du à la compilation est plus grand.
 
[[:File:integration_intensite_lopy_pour_un_cycle.jpg]]


Porteurs: David / Bernard
Si on veut faire 50 000 mesures, elles vont durer 50 000 *(3.5s + 1.5s) / 3600 = 70 heures, soit 8300 mAh avec une consommation de 120 mA.


Actuellement il y a 2 pistes:
 
* LoRa + Arduino (Bernard)
** il faudra donc (1000 + 8300) = ~9000mAh, soit 3 batteries de 3000 mAh.
* LoRa mDot (David)
On ne tient pas compte de l'auto-décharge, qui est faible avec les batteries Lithium.
 
==Arduino Lora==




=== Principe ===


Le module
Actuellement il y a 3 pistes:
* doit avoir une autonomie de 1 an
* LoRa + Arduino : abandon, prix shield >> et conso >>
* envoi les données brute de ses capteurs
* LoRa + Lopy : retenue
* peut avoir plusieurs capteurs
* LoRa + ESP32 : à creuser, retenue pour Projet Macareux qui est très similaire
* doit pouvoir être réveillé sur interruption + timer


=== Lora + Arduino ===
=== Lora + Arduino ===


*Le module HX711 émet un signal numérique sur la broche DOUT (data out) lorsqu'il est piloté par la broche SCK.
* Il est connecté sur les broches I/O de l’Arduino
* On peut mettre 4 HX711 sur l’Arduino en l'état actuel, à voir si on peut multiplexer les capteurs sur 2 broches. Pas utile en fait, il y a assez de broches sur Arduino ou Lopy.
* Le module LoRa (shield W6Labs, Rennes)[https://froggyfactory.com/shop.php#shop : carte pour Arduino], utilise les pins 10-11-12-13


=== LoRa mDot ===
=== LoRa mDot ===


MTDOT-868-X1P-SMA-1 - http://www.multitech.com/models/94557138LF
Piste abandonnée : MTDOT-868-X1P-SMA-1 - http://www.multitech.com/models/94557138LF


Fait:
== Conformité à LoRa ==
* Lecture de la valeur envoyée par le HX711
 
La norme LoRa impose deux critères : temps d'occupation global de l'espace aérien (airtime de 30 secondes par jour pour TTN) et temps d'occupation d'une sous-bande de 1%. Voir par exemple : https://forum.thethingsnetwork.org/t/limitations-data-rate-packet-size-30-seconds-day-fair-access-policy-nodes-per-gateway/1300
 
Trame LoRa : il y a  13 octets pour l'encapsulation WAN  (qui peut monter à 23 o en cas de join request,
voire jusqu'à 28 o ), mais il ne faut pas oublier les 10,25 temps symboles du préambule de la couche physique (en SF8 ça fait 10 o), avec en plus 5 o optionnels pour header et CRC, soit minimum de 23 octets pouvant aller à 43 o.
cf : https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5038744/
 
Avec le calculateur joint [[:File:LoRa(WAN) airtime calculator.ods]] , en SF8, on trouve que la ruche peut émettre 323 mesures de 2 octets par jour, 224 mesures de 20 o et 182 à 30 octets, compatible avec un cycle de 10 minutes (24*6=144).
Les durées d'émission, en SF8, iraient de 92 ms à 164 ms pour une payload (charge utile) de 2 à 30 o.


TODO:
En bref, jusqu'à 30 octets, on peut presque négliger l'importance de la payload....
* Tester la connexion à la passerelle (en attente de passerelle)
* Réveil par interruption + Timer (cf lib beta: https://developer.mbed.org/questions/61619/mDot-deep-sleep-mode-wake-up/)


</div>
== Fiabilité ==
== Gateway LoRa ==


Porteur: ???
La fiabilité recouvre plusieurs aspects :  
* fiabilité physique des composants (en particulier de la batterie, qui pourrait vieillir assez vite)
* fiabilité logicielle : on a vu que l'on faisait 50 000 mesures par an, soit 50 000 fois la compilation. Sur les premières versions de Lopy4, au bout de 500-2000 mesures, celui "plante" une fois pendant la compilation, reste dans un état intermédiaire (le chien de garde qui "tourne" sur le logiciel actif est alors inopérant) et vide la batterie en quelques jours. La dernière version semble mieux se comporter...
* fiabilité des mesures : il ne s'agit pas de lancer des alarmes à tort et à travers, à tout moment, à cause d'une mauvaise mesure. La programmation des HX711 a due être revue pour obtenir une bien meilleure fiabilité.
Il y a quelques fois des mesures hors norme, mais on peut les rejeter en les opposant aux valeurs des trois autres capteurs. Si trois capteurs sont stables et que le quatrième s'égare, on déclare la mesure fausse et on attend un cycle.


== Web ==
== Web ==
Ligne 143 : Ligne 201 :
* Modèle de données
* Modèle de données
* API Rest
* API Rest
TODO:
* Restreindre l'accès à une partie de l'API -> NOK
* Ajouter la fonction de déclaration de la tare -> se fait dans le fichier config.py associé à chaque Lopy
* Ajouter la fonction de transformation de donnée brute en donnée normée -> NOK. Est ce utile? Les données sont envoyées en grammes.
* Grapher les données des capteurs -> OK en local (cf fichier joint), NOK sur TTN + ATTM
* Ajouter les fonctions web d'ajout/suppression/modification de ruches/capteurs/modules -> NOK
lien :
http://letmeknow.fr/blog/2015/10/27/tutomodulelora/


==Liste du matériel-Coût==
==Liste du matériel-Coût==
Ligne 158 : Ligne 227 :
* Pas de coûts d'utilisation des réseaux Lora
* Pas de coûts d'utilisation des réseaux Lora


Total : environ 85€ TTC pour un chassis autonome  
Total : environ 90 € TTC pour un chassis autonome
 
 
 
TODO:
* Restreindre l'accès à une partie de l'API -> NOK
* Ajouter la fonction de déclaration de la tare -> se fait dans le fichier config.py associé à chaque Lopy
* Ajouter la fonction de transformation de donnée brute en donnée normée -> NOK. Est ce utile? Les données sont envoyées en grammes.
* Grapher les données des capteurs -> OK en local (cf fichier joint), NOK sur TTN + ATTM
* Ajouter les fonctions web d'ajout/suppression/modification de ruches/capteurs/modules -> NOK
 
 
lien :
http://letmeknow.fr/blog/2015/10/27/tutomodulelora/


== Liens Web ==
== Liens Web ==
Ligne 181 : Ligne 237 :
Lopy: choisir boot.py (RX comme récepteur point à point)ou boot_sans_wifi.py (TX comme émetteur) selon que l'on est en mode local ou distant, main.py (correspond à version_v_18), config.py (correspond à version_v_18) et HX711.py
Lopy: choisir boot.py (RX comme récepteur point à point)ou boot_sans_wifi.py (TX comme émetteur) selon que l'on est en mode local ou distant, main.py (correspond à version_v_18), config.py (correspond à version_v_18) et HX711.py


Présentation du projet Bzz début 2019 [[:File:BZZZ_2.pptx]]
Présentation du projet Bzz en juin 2019 [[:File:bzz_2019.odp]]
 
Présentation du projet Bzz en 2018 [[:File:BZZZ_2.pptx]]


Balance connectées pour ruches : http://itsap.asso.fr/outils/balances-automatiques/
Balance connectées pour ruches : http://itsap.asso.fr/outils/balances-automatiques/


http://makerspace56.org/wiki/asso-wiki/projets/la-ruche-connectee/capteurs-et-composants/
http://makerspace56.org/wiki/asso-wiki/projets/la-ruche-connectee/capteurs-et-composants/
https://www.thethingsnetwork.org/forum/t/the-beehive-topic/25599/37
https://makerslab.em-lyon.com/makers-beehive.html


= Communication autour du projet =  
= Communication autour du projet =  
Ligne 215 : Ligne 277 :


<gallery>
<gallery>
DSCF1946.jpg|Ruche supervisée
DSCF1946.jpg|Ruche demi-châssis supervisée (Rucher Orange-Lannion)
DSCF1949.jpg|Boîtier Étanche
DSCF1949.jpg|Boîtier Étanche
DSCF1948.jpg|Boîtier Étanche
DSCF1948.jpg|Boîtier Étanche
DSCF1957.JPG|Boîtier Étanche
DSCF1957.JPG|Boîtier Étanche
DSCF1956.JPG|Ruche supervisée
DSCF1956.JPG|Ruche demi-châssis supervisée
DSCF1955.JPG|Ruche supervisée
DSCF1955.JPG|Ruche demi-châssis supervisée
DSCF1954.JPG|Ruche supervisée
DSCF1954.JPG|Ruche demi-châssis supervisée
Attention_au_merle_DSCF2228.JPG|Pèse-ruche autonome Arduino
</gallery>
</gallery>


[[Category:Projet]]
[[Category:Projet]]
[[Category:LoRa]]
[[Category:LoRa]]

Version actuelle datée du 19 septembre 2020 à 08:49

Logo projet Bzzz


Présentation

Le projet Bzzz (Bee Zen Cube) est un projet de suivi de ruches pour une apiculture plus anticipative, il a pour but de proposer gratuitement à tout apiculteur amateur les plans d'un kit de supervision de son rucher (châssis de mesure autonome, et si le prix des émetteurs LoRa reste élevé réaliser une station d'émission qui centraliserait plusieurs châssis secondaires). Le projet Bzzz suit l'évolution de la santé de la ruche à distance, principalement par la mesure des variations de poids, la température locale et donner l'alerte en cas d'essaimage ou surtout, de la préparation de l'essaimage. On fait tout cela pour éviter de multiples déplacements de l'apiculteur.

Le projet Bzzz est un projet Open-source et Open-hardware

Ce projet fédère plusieurs bénévoles au sein du fablab et est suivi par les médias locaux ainsi que par des apiculteurs d'autres régions (volontaire pour prototypage notamment). Plusieurs apiculteurs ont aussi fait le déplacement au sein du FabLab de Lannion pour venir découvrir ce projet et se porter volontaire pour une période de béta-test dés que la solution sera pleinement fonctionnelle.


Participants

  • Bernard Arzur
  • Frédéric Carré
  • David Blaisonneau
  • Thierry Houdouin
  • Jérôme Labidurie
  • Tangi Lavanant
  • François-Xavier Potel
  • Morgan Richomme

Chassis / Capteurs

Porteur: Bernard

Module Chassis

Demi-Chassis (abandonné)

  • Une seule jauge de contrainte (50 kg) par capteur/demi-chassis(diminution du prix)
  • On accède au paramètre de variation du poids
  • La valeur absolue du poids de la ruche n'est pas connue
  • On peut voir le shield W6Labs associé à un Arduino UNO et un HX711.

DemiRuche.jpeg DSCF1946.jpg

2 Demi-Chassis (abandonné)

  • Le support associé est remplacé par un 2éme demi-chassis
  • Le poids exact est connu par la somme des 2 valeurs issues des 2 capteurs
  • Le coût est un peu plus élevé


Chassis autonome

Cette solution, simple, a été rendue possible par la forte baisse du prix des composants (LoRa, jauges, ...) et aussi par la réduction drastique de la consommation du Lopy4 en mode veille (=> abandon de l'Arduino associé à une carte économiseur).

  • Quatre jauges de contrainte par châssis.
  • On accède aux paramètres de poids dans l'absolu, de la variation du poids, et aussi du centre de gravité (placement de l'essaim dans la ruche et des cadres remplis).
  • La valeur absolue du poids de la ruche est connue, mais il ne faut pas oublier la variation due à l'humidité du bois (peut monter à 15% du poids du bois de la ruche) et la correction nécessaire pour compenser les écarts thermiques. Comme on mesure des microvolts, le moindre effet de couple thermo-électrique est largement amplifié : éviter soudures, connectiques...

Cahier des Charges :

-système autonome pendant une année entière

-l'ensemble des composants doit fonctionner entre -30°C et +70°C

-une mesure toutes les 10 minutes, y compris pendant la nuit (éviter le vol de ruche), soit ~50 000 mesures/an

-précision souhaitée : 10 grammes (100 abeilles) pour une masse maximum de 100 kg

-compatibilité avec la norme LoRa (durées et fréquences d'émission)

-coût inférieur à 100 €

-pas de câbles ni fils visibles

-hauteur maximum 30 mm

-gestion simple

Mesure du poids

  • Il est connu à 10 grammes près, sur une plage de 0 à 100 kg, avec des jauges de 20 kg. Si on vise au-delà de 80 kg (4*20kg), il existe des jauges de 50 kg beaucoup plus coûteuses et forcément un peu moins précises.
  • Mesuré par une jauge de contrainte résistive connectée en un pont de Wheatstone [1]
  • Numérisation de la mesure (0-10mV) par un module HX711 (convertisseur analogique/numérique à 24 bits de précision)
  • Le module HX711 est connecté au plus près de la jauge, pour éviter les interférences électromagnétiques et les effets thermiques (thermo-couple). Les effets thermiques sur la résistance de mesure sont en principe compensés par l'utilisation d'une autre résistance montée en orthogonal sur la jauge.
  • Le module HX711 est connecté au module d'émission IoT, qui peut donc en recevoir plusieurs. Avec Lopy, il a été impossible d'utiliser un canal de données commun (DOUT), alors qu'avec Arduino, cela fonctionne. Comme on dispose d'assez d'entrées/sorties, la question se résout facilement : chaque HX prend une entrée (DOUT) et une sortie (SCK).

Arrachage / Vol

Alarme au bout de 10 minutes maximum, sur variation de poids brutale

Alarme instantanée sur capteur de contact, optionnel

Châssis autonome (Mesure et Émission)

Boitier

L'idée, au départ, était d'avoir un boîtier avec émetteur RF qui collecte plusieurs balances sans émetteur, voire sans batterie, vu le prix élevé des composants à ce moment...

  • Il doit être étanche, résistant car il restera à l'extérieur plusieurs années.
  • Il doit donc être de catégorie IP64 au moins. Nous avons choisi IP65 pour une meilleure fiabilité à long terme.
  • Ce boîtier contiendra :
    • L'alimentation électrique (batterie lithium + carte économiseur)
    • Arduino + carte Lora
    • Antenne
  • Nous avons donc choisi un boîtier "Raccordement Fibre Optique" qui permet d'ajouter facilement des entrées-sorties -> abandon, on ne veut plus de fils/cables autour de la ruche, pour des raisons de sécurité et de fiabilité.

Alimentation solution Arduino

  • Batterie de 4 éléments de 2800mAh
  • La carte économiseur (basée sur 3 relais basse consommation Reed et un Ampli-Op LM324) permet de diviser la consommation par 100 :
    • 1 mA en consommation moyenne > 6 mois d'autonomie prévue
    • 0.6mA au repos
    • 120mA en émission (qq secondes toutes les 10 min)

Cependant, l'autonomie obtenue est insuffisante et la carte économiseur revient cher (>20€).

Alimentation solution Lopy

Solution retenue : 3 Batteries de 3000mAh

La carte Lopy4 (pas toutes les versions, malheureusement!) dispose d'une mise en veille profonde : elle coupe l'alimentation du processeur principal, et la consommation chute à une valeur très faible, entre 20 µA et 200µA. Cette consommation varie à la hausse si on utilise la carte Expansion Board pour connecter le Lopy4. On essaiera de s'affranchir de cette carte, à cause de son prix (~20€), de sa conso (due entre autre autres au pont diviseur pour mesurer la tension batterie) et des limitations du chargeur de batterie (500 mA max). On la remplace par un circuit de charge, un pont diviseur de haute impédance et on soude directement le Lopy sur le circuit imprimé.

Pour se maintenir en veille, les HX711 ont besoin d'être polarisés en tension sur la broche SCK, il faut monter des résistances de pull-up d'environ 1 MOhm entre SCK et +3.3V. Sinon, chaque HX711 pourrait rajouter 8 mA à la consommation de veille.


    • 10 000 heures(~une année) au repos représentent donc, pour 100µA -> 1000 mAh
    • Lorsque Lopy4 se réveille, il doit recompiler son code : ça prend entre 2,5 s (70 lignes) et 3.5 s (250 lignes) selon la complexité du programme et l'appel aux différentes bibliothèques. Puis il effectue la mesure de poids et envoie le paquet LoRa.

La durée de transmission LoRa est minimisée en configuration RAW : on transmet le paquet en clair vers un récepteur calé sur la même fréquence. Le type de trame est le suivant : "labeld4212dbzz3d284d452d406d233d", soit 32 à 40 octets, label permet d'identifier que c'est notre trame, d est le délimiteur avec le champ suivant qui est la tension batterie, bzz3 est le nom de la ruche tel qu'on l'a défini sur TTN par exemple, puis les quatre poids en grammes. La somme des 4 donne le poids total et sa position en 2D.

On peut transmettre en APB vers une GateWay de TTN par exemple. On envoie d'abord plusieurs champs que TTN aura calculé au préalable : un champ de 8 octets pour l'identité d'émetteur, un champ de 32 octets pour l'application et un champ de 32 octets pour l'identité du réseau. Et puis, on envoie notre trame sans le champ label, qui est remplacé par les champs TTN. On devine que ce deuxième mode APB sera un peu plus lent et plus gourmand en énergie et bande passante(70 octets de plus) et pas forcément compatible avec les critères LoRa.

Le mode OTAA n'a pas été considéré, il nécessite régulièrement un échange bidirectionnel avec la GateWay de TTN pour maintenir notre émetteur sur le réseau TTN, entraînant une surconsommation d'énergie.

Le courant absorbé varie durant le cycle entre 40 mA (compilation), 140 mA (mesure) et 200 mA (envoi paquet LoRa), avec une moyenne à 120 mA pour un cycle de 14s. Pour 5 s, l'intensité moyenne devrait être plus basse (à vérifier), puisque le % du à la compilation est plus grand.

File:integration_intensite_lopy_pour_un_cycle.jpg

Si on veut faire 50 000 mesures, elles vont durer 50 000 *(3.5s + 1.5s) / 3600 = 70 heures, soit 8300 mAh avec une consommation de 120 mA.


    • il faudra donc (1000 + 8300) = ~9000mAh, soit 3 batteries de 3000 mAh.

On ne tient pas compte de l'auto-décharge, qui est faible avec les batteries Lithium.

Arduino Lora

Actuellement il y a 3 pistes:

  • LoRa + Arduino : abandon, prix shield >> et conso >>
  • LoRa + Lopy : retenue
  • LoRa + ESP32 : à creuser, retenue pour Projet Macareux qui est très similaire

Lora + Arduino

  • Le module HX711 émet un signal numérique sur la broche DOUT (data out) lorsqu'il est piloté par la broche SCK.
  • Il est connecté sur les broches I/O de l’Arduino
  • On peut mettre 4 HX711 sur l’Arduino en l'état actuel, à voir si on peut multiplexer les capteurs sur 2 broches. Pas utile en fait, il y a assez de broches sur Arduino ou Lopy.
  • Le module LoRa (shield W6Labs, Rennes): carte pour Arduino, utilise les pins 10-11-12-13

LoRa mDot

Piste abandonnée : MTDOT-868-X1P-SMA-1 - http://www.multitech.com/models/94557138LF

Conformité à LoRa

La norme LoRa impose deux critères : temps d'occupation global de l'espace aérien (airtime de 30 secondes par jour pour TTN) et temps d'occupation d'une sous-bande de 1%. Voir par exemple : https://forum.thethingsnetwork.org/t/limitations-data-rate-packet-size-30-seconds-day-fair-access-policy-nodes-per-gateway/1300

Trame LoRa : il y a 13 octets pour l'encapsulation WAN (qui peut monter à 23 o en cas de join request, voire jusqu'à 28 o ), mais il ne faut pas oublier les 10,25 temps symboles du préambule de la couche physique (en SF8 ça fait 10 o), avec en plus 5 o optionnels pour header et CRC, soit minimum de 23 octets pouvant aller à 43 o. cf : https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5038744/

Avec le calculateur joint File:LoRa(WAN) airtime calculator.ods , en SF8, on trouve que la ruche peut émettre 323 mesures de 2 octets par jour, 224 mesures de 20 o et 182 à 30 octets, compatible avec un cycle de 10 minutes (24*6=144). Les durées d'émission, en SF8, iraient de 92 ms à 164 ms pour une payload (charge utile) de 2 à 30 o.

En bref, jusqu'à 30 octets, on peut presque négliger l'importance de la payload....

Fiabilité

La fiabilité recouvre plusieurs aspects :

  • fiabilité physique des composants (en particulier de la batterie, qui pourrait vieillir assez vite)
  • fiabilité logicielle : on a vu que l'on faisait 50 000 mesures par an, soit 50 000 fois la compilation. Sur les premières versions de Lopy4, au bout de 500-2000 mesures, celui "plante" une fois pendant la compilation, reste dans un état intermédiaire (le chien de garde qui "tourne" sur le logiciel actif est alors inopérant) et vide la batterie en quelques jours. La dernière version semble mieux se comporter...
  • fiabilité des mesures : il ne s'agit pas de lancer des alarmes à tort et à travers, à tout moment, à cause d'une mauvaise mesure. La programmation des HX711 a due être revue pour obtenir une bien meilleure fiabilité.

Il y a quelques fois des mesures hors norme, mais on peut les rejeter en les opposant aux valeurs des trois autres capteurs. Si trois capteurs sont stables et que le quatrième s'égare, on déclare la mesure fausse et on attend un cycle.

Web

Porteur: David

Principe

  • L'utilisateur ajoute une ruche > un module > N capteurs
  • L'utilisateur configure chaque capteur si besoin (tare, échelle)
  • L'utilisateur configure le seuil de déclenchement des alertes
  • Le site web recoit les données brutes des capteurs via la passerelle et les transforme en données utile si besoin
  • Le site web graph les données
  • Le site web alerte l'utilisateur si un seuil est franchi.

Taches

Fait:

  • base Web2Py
  • Site de base avec authentification
  • Modèle de données
  • API Rest

TODO:

  • Restreindre l'accès à une partie de l'API -> NOK
  • Ajouter la fonction de déclaration de la tare -> se fait dans le fichier config.py associé à chaque Lopy
  • Ajouter la fonction de transformation de donnée brute en donnée normée -> NOK. Est ce utile? Les données sont envoyées en grammes.
  • Grapher les données des capteurs -> OK en local (cf fichier joint), NOK sur TTN + ATTM
  • Ajouter les fonctions web d'ajout/suppression/modification de ruches/capteurs/modules -> NOK


lien : http://letmeknow.fr/blog/2015/10/27/tutomodulelora/

Liste du matériel-Coût

L'ensemble des composants doit fonctionner entre -30° C et +70°

Configuration Point à point

voir le fichier pour les composants

File:composants_balance_ruche_bzzz.odt

et un devis estimatif sur: File:septembre_2019__ruche.ods

  • Récepteur Arduino/Lora : 50€ qui peut servir pour x émetteurs à portée (c'est un Lopy connecté à un PC ou configuré en GateWay)
  • Pas de coûts d'utilisation des réseaux Lora

Total : environ 90 € TTC pour un chassis autonome

Liens Web

Logiciels pour Lopy et Arduino : https://github.com/bernardarzur/bzzz

Arduino : choisir tx_rx_v_3_simplifiée.ino

Lopy: choisir boot.py (RX comme récepteur point à point)ou boot_sans_wifi.py (TX comme émetteur) selon que l'on est en mode local ou distant, main.py (correspond à version_v_18), config.py (correspond à version_v_18) et HX711.py

Présentation du projet Bzz en juin 2019 File:bzz_2019.odp

Présentation du projet Bzz en 2018 File:BZZZ_2.pptx

Balance connectées pour ruches : http://itsap.asso.fr/outils/balances-automatiques/

http://makerspace56.org/wiki/asso-wiki/projets/la-ruche-connectee/capteurs-et-composants/

https://www.thethingsnetwork.org/forum/t/the-beehive-topic/25599/37

https://makerslab.em-lyon.com/makers-beehive.html

Communication autour du projet

La présentation de l'idée de départ:Fichier:Projet Bzzz.pdf

Bzz au carrefour des possibles

Une petite vidéo de présentation du projet Bzzz au carrefour des possibles Video Vimeo

Les 10 projets Juin 2013

Le télégramme de novembre 2013 Explication du dispositif au Télégramme en novembre 2013 disponible en vidéo

Liens utiles

site de test (login test mdp <rien> )

Code

code serveur [2]


Photos