Hiba Belmaate¶

hello world !

Contexte¶

J’ai travaillé sur l’amélioration de la carte électronique existante afin de proposer une nouvelle version fusionnée entre les projets Mellia et OpenBeeLab.

L’objectif est de concevoir une carte plus adaptée à une ruche connectée, capable de gérer l’alimentation, l’acquisition des mesures, la communication et le pilotage du système mécanique. L’idée n’est pas simplement de recopier la carte existante, mais de l’adapter à un système plus économique, plus modulaire et plus simple à tester.

Avant de modifier le schéma, j’ai étudié les documentations disponibles pour comprendre le rôle des différents blocs : alimentation, ADC, microcontrôleur, communication, capteurs et partie moteur. Cette analyse m’a permis d’identifier les éléments indispensables à conserver et ceux qui pouvaient être supprimés ou remplacés.

Choix techniques retenus¶

Le principal choix d’architecture concerne la suppression de la jauge de contrainte. Elle permet une mesure directe du poids, mais elle représente un coût important dans la carte. Pour cette nouvelle version, nous avons donc choisi de nous orienter vers une solution basée sur le principe mécanique d’OpenBeeLab.

La mesure ne serait plus directement réalisée par une jauge, mais par l’exploitation du mécanisme, du déplacement motorisé et d’un capteur optique. Le capteur optique présente l’avantage de réaliser une détection sans contact, ce qui limite l’usure mécanique et évite d’ajouter des frottements dans le système.

L’ADC est conservé afin de garder une acquisition précise du signal analogique associé au capteur optique. La carte garde ainsi une partie de la qualité électronique de Mellia, tout en réduisant le coût lié à la cellule de charge.

Un point important du schéma est la séparation entre la partie analogique et la partie numérique. La partie analogique regroupe l’ADC, la référence de tension et le signal du capteur optique. La partie numérique regroupe le microcontrôleur, les GPIO, l’ESP32, les commandes moteur et les interfaces de communication. Cette séparation permet de limiter l’influence du bruit généré par les commutations numériques ou par le moteur sur les mesures analogiques.

Schéma réalisé sous KiCad¶

J’ai réalisé un premier schéma de la carte fusionnée sous KiCad. Le schéma est organisé en deux zones afin de mieux distinguer ce qui appartient à la carte principale et ce qui sera placé à l’extérieur ou accessible depuis le boîtier.

Dans la partie carte physique, j’ai conservé les blocs nécessaires au fonctionnement de base :

• convertisseur DC/DC ;
• régulateur de tension ;
• diode de protection ;
• référence de tension ;
• ADC ;
• MCU ;
• capteur HTP ;
• interfaces de connexion.

J’ai supprimé le bloc de la jauge de contrainte et adapté le schéma pour intégrer une mesure basée sur le capteur optique.

J’ai aussi ajouté un ESP32, relié à la carte par un socket/connecteur. Ce choix permet de garder une architecture plus flexible : l’ESP32 pourra être testé, remplacé ou modifié sans devoir refaire toute la carte.

Éléments ajoutés pour l’usage terrain

Dans la partie externe, j’ai ajouté les éléments liés à l’utilisation réelle du système dans une ruche :

• le panneau solaire pour l’alimentation ;
• la sonde SHT20 pour la température et l’humidité ;
• le driver moteur ;
• le moteur pas à pas ;
• des LED indicatrices ;
• un bouton poussoir de tare.

Le bouton poussoir de tare est placé dans la partie externe du boîtier pour être facilement accessible à l’apiculteur. Il permettra de remettre la balance à zéro sans ouvrir le boîtier, ce qui rend l’utilisation plus pratique sur le terrain.

Un interrupteur ON/OFF est également prévu dans la partie interne de la carte. Il servira à couper ou réactiver l’alimentation lors des phases de test, de maintenance ou de stockage.

Les LED indicatrices sont ajoutées pour faciliter le diagnostic rapide : elles pourront aider à vérifier si la carte est alimentée, si le système est actif ou si une phase de test est en cours.

Travail en cours¶

Le schéma de fusion est maintenant réalisé dans KiCad. Avant de commencer le routage, nous attendons le Git de la carte déjà existante afin de repartir d’une base correcte et éviter de refaire des choix incompatibles avec la carte d’origine.

En attendant, je vais avancer sur la validation de la partie moteur. L’objectif est de tester le pilotage du moteur pas à pas avec un programme de base et la carte de test de OpenHiveScale. Ce test permettra de vérifier les signaux de commande, le driver moteur et la rotation dans les deux sens avant l’intégration complète dans la nouvelle carte.