Cartographie 3D
Cartographie 3D
Pour obtenir une carte avec une imprimante 3D
Ce site vous permet de sélectionner la zone géographique qui vous intéresse et d’exporter le fichier en .stl. Il ne vous reste plus qu’à le transformer en gcode pour l’imprimante 3D !
Petit conseil : redimensionner votre carte en jouant sur l’axe des z dans votre logiciel de slicing pour avoir un bon rendu.
Pour obtenir une carte avec des aplats superposés
Ce site vous permet de sélectionner la zone géographique qui vous intéresse et d’exporter le fichier en .stl. Le logiciel Slicer for Fusion 360 vous permet de découper ce modèle 3D en couches. Pour plus de détails sur les différents types de découpe (appelées « Construction technique ») possible, ce tuto est très bien.
Ici on choisira « stacked slices ». L’onglet « get plans » permet de visualiser les plans. Un bouton en bas de page permet d’exporter sur l’ordinateur en différents formats (par exemple pdf).
Ouvrir ce pdf sur inkscape ou Corel Draw afin de bien paramétrer pour la découpe. Découper. Coller dans le bon ordre les différents aplats !
Pour obtenir une carte customisée
Sélectionner votre zone sur Open Street map par exemple.
La plaque de bois du fond peut être peinte (en bleu s’il y a de l’eau) ou gravée avec des détails du fond.
Créer un fichier pour les rues : pour cela importer votre carte open street map (même une impression écran suffira), vectorisez-la ou faite le tracé des rues à la main avec l’outil courbes de Bézier. Attention à l’épaisseur des ruelles et ajouter bien un cadre de 1 cm tout autour ! Découper à la découpeuse laser. Coller la découpe des rues sur le fond de carte en bois.
Pour obtenir une carte topographique à partir d’un bloc de bois
Mekanika a fait un super tuto ! Il s’agit de fraisage à la fraiseuse CNC.
Communication peer to peer LoRa-E5 | Arduino Leonardo
Prérequis
|
Arduino Leonardo[1] |
Module Grove Base Shield[2] |
Module LoRa-E5 Grove[3] |
Connecteur UART[4] |
 |
 |
 |
 |
Afin de mettre en place cette communication, j’ai dû m’inspirer du code de Sylvain Montagny présent sur son github[5].
Pour simplifier les choses, j’ai séparé la partie réception de la partie transmission mais chaque carte est en mesure d’envoyer et recevoir des informations.
Les prochaines illustrations et tests ont été effectués à l’aide du logiciel « Arduino IDE » téléchargeable sur cette page[6].
Amélioration de Primo de Cubetto
Dans le cadre du projet CODEVSI, un groupe de 3 étudiants s’est vu confier la tâche de d’améliorer les fonctionnalités de la version open source du robot Cubetto.
Le Cubetto est un robot destiné à l’enseignement des bases de la programmation aux enfants, permettant une introduction ludique et interactive au codage.
Il est composé d’un robot motorisé en bois, d’un tapis sur lequel il se déplace et d’une interface de commande permettant de programmer ses mouvements à l’aide de blocs physiques.
Un problème majeur a été identifié dans la version open source : le manque de précision dans les déplacements du robot dû au système de pilotage des roues. Ce dernier utilisait un capteur optique couplé à un moteur à engrenages, pour suivre la rotation des roues en comptant les
traits noirs et blancs.
Le groupe a conçu une solution de remplacement, incluant une modification complète du système de pilotage :
– des moteurs pas à pas 28BYJ-48 disponibles au Fablab ont remplacé les moteurs à engrenage
– les drivers moteurs associés ont été remplacés
– le code Arduino a été modifié en conséquence pour asservir le moteur pas à pas
– une breadboard a été ajoutée pour assurer l’alimentation des deux moteurs
Pour assurer la meilleure précision possible, il a été nécessaire de :
– modéliser puis imprimer en 3D un joint d’adaptation entre la roue et l’arbre-moteur
– modéliser puis réaliser en 3D un support de fixation pour le moteur sur la carrosserie
Par ailleurs, une nouvelle fonctionnalité de détection des obstacles a été ajoutée. Ceci est réalisé à l’aide d’un capteur ultrason de modèle HC-SR04 lui aussi disponible au Fablab.
Le code Arduino principal a intégré le fonctionnement du capteur optique.
Finalement, une nouvelle carrosserie a été fabriquée à l’aide de la découpeuse laser du Fablab pour être adaptée au nouveau capteur ultrason et pour contenir l’ensemble des nouveaux composants.
Une fois le nouveau modèle assemblé, une série de tests a été exécutée pour vérifier le bon fonctionnement du robot et du nouveau système, assurant ainsi que les améliorations apportées répondaient aux attentes et aux exigences du projet.
Membres du groupe : Khalil SOUGUIR, Ylan TEISSIER, Marie-Joséphine EDOA
Annexes :
Code Arduino du robot
Joint d’adaptation entre la roue et l’arbre-moteur
Objets animés
Phare animé, tableau marin lumineux, oiseaux animés… De nombreux objets peuvent être conçus avec les élèves et animés grâce à de la programmation graphique, des LEDs et des servomoteurs !
Voici un exemple de phare lumineux réalisé pour des animations en classe de CM2 à Bourg Blanc (article ici) et en CM1/CM2 à Coray avec la mallette MERITE « Objets animés ».
 Intérieur du phare, un pan reste amovible (non collé) pour voir les composants électroniques |
 la mouette est mobile grâce au servomoteur, la LED vert clignote en haut du phare |
 le phare réalisé par les CM2 de Bourg Blanc (réinvestissement de ce qu’ils avaient vu en arts plastiques) |
Le fichier utilisé pour le phare de démonstration est disponible ici. Il a été découpé sur une plaque de CP peuplier 3mm.
La partie du haut n’est pas collé à celle du bas (pour le transport et pour montrer l’assemblage aux élèves). Une face latérale du phare reste également amovible. La LED et le servomoteur tiennent avec de la patafix. Un autre trou permet aussi de mettre le servomoteur dans la partie du haut. Les autres faces de la parties du bas sont collées à la colle à bois, de même que les faces de la partie du haut.
En se servant de la mallette on peut aussi aller plus loin avec des boutons poussoirs, des photorésistances… Tout dépend du projet !
Le projet avec les phares a été fait en 3h30 + 2h pour la partie programmation, plus 2h pour la partie réalisation du phare des élèves.
Shut the box
Jeu de stratégie et de dés
« Shut the box » est un jeu très simple, qui peut se jouer de 1 à 4 joueurs de préférence.
Objectifs pédagogiques :
– travailler la décomposition des nombres de 1 à 9
Règles du jeu :
Placer tous les taquets chiffrés à la verticale. Lancer les 2 dés. Choisir quel.s taquet.s baisser : la somme des chiffres sur les taquets doit correspondre à la valeur totale obtenue en ayant lancé les 2 dés.
Exemple : Si on a obtenu 5 et 1 sur les dés on pourra donc baisser les taquets 5 et 1 ou seulement le 6 ou le 2 et le 4.
Quand les taquets de 7 à 9 sont abaissés, le joueur de lance plus qu’un dé.
Le joueur ayant abaissé tous ses taquets en premier à gagné (il a « fermé la boite »). Dans la version à 1 joueur il faut abaisser tous ses taquets en un minimum de lancer de dés.
Fabrication du jeu
Découpe et gravure à la découpeuse laser du fichier. Fichier utilisé modifié à partir du Shut the Box with Double Score Tracks de Kap42:
(licence CC BY-NC-SA). 2 plaques de MDF 3 mm et 1 plaque de MDF 6mm de 45×30 cm.
Tetra’aides
Le Tetra’aide a été conçu par Bruce Demaugé-Bost, professeur des écoles dans le Rhône. Ce dispositif en forme de tétraèdre est posé sur la table et permet de signaler facilement :
– lorsque tout va bien avec la face verte vers le haut
– si l’élève aide ou se fait aider par quelqu’un (et donc discute en peu) avec la face bleue vers le haut
– si l’élève à une question non urgente avec la face jaune vers le haut. L’enseignant passera lorsqu’il sera disponible.
– l’élève a un besoin urgent d’aide avec la face rouge vers le haut.
Il existe de très nombreuses versions. En voici une sélection :
| Une version en bois réalisée à la découpeuse laser puis peinte à la gouache |  |
| La version tourillons en bois permet de limiter l’impression 3D. Elle fait 11 cm de haut et nécessite 6 tourillons en bois de 9mm de diamètre et 6 cm de long. |
 Tetra’aide tourillon bois, thingiverse dThibault |
| Une version tissu réalisable avec la machine à coudre du fablab |
 Tetra’aide anti-stress, auteur : Mathilde Pérain |
Disques des fractions et des pourcentages
Disques de fractions et des pourcentages
Ces disques des fractions réalisés en bois permettent de facilement manipuler le concept de fraction (1/1, 1/2, 1/3, 1/4, 1/5, 1/8ème).
Les disques des pourcentages (100%, 50%, 25%, 20%, 12,5%) sont de même diamètre : ils peuvent être utilisés indépendamment des disques des fractions ou ensemble.
On peut par exemple faire le lien entre 50% et 1/2 en joignant sur le support les deux demi-disques correspondants.
Les fichiers ont été utilisés sur du MDF 3 mm avec la découpeuse laser, gravure (100% puissance, 30% vitesse), découpe (100% puissance, 0,7% vitesse).
Puzzles êtres vivants
Au départ, ce projet a été réalisé pour créer des puzzles pour un petit de 2 ans, dans la lignée des puzzles Montessori. Il est très facile de hacker les fichiers pour créer un puzzle plus complexe, abordant un autre sujet, avec davantage de pièces…
Les réalisation sont faites en CP peuplier 3mm : un rectangle sert de socle. Les pièces du puzzle et le rectangle dans lequel elles sont découpées sont également en CP peuplier 3 mm. Le rectangle sert de cadre pour aider l’enfant à insérer les formes. Socle et cadre sont collés ensemble avec de la colle à bois.
Différents diamètres de disques en bois ont été testés : le plus efficace à 2 ans semble être un disque de 6mm d’épaisseur et de 4 mm de diamètre. Un disque est collé par pièce pour faciliter la préhension de la pièce de puzzle.
Les pièces du puzzle sont peintes à la peinture acrylique. De la gouache + de vernis à eau peut également convenir.
DeepBlue Tracker – Solution technique
DeepBlue Tracker – Solution technique
par Antoine DAGORN Salomón OJEDA Clément LERICHE Théo BARTHÉLEMY Daniel TAPIA
V2 – 15 janvier 2024
1. Mise en contexte du projet
Dans le cadre du projet fil rouge de la TAF Conception d’objet communicant de l’école d’ingénieur IMT Atlantique, nous avons travaillé sur un projet concernant la sécurité maritime.
Les activités nautiques solitaires sans flotteur, comme la plongée en apnée, la chasse sous-marine et la natation en eau libre en mer, offrent une expérience immersive exceptionnelle, mais présentent des défis importants en termes de sécurité. Des situations d’urgence, telles que la perte d’orientation, les changements météorologiques, les accidents ou les problèmes de santé, peuvent survenir à tout moment. Le défi consiste à assurer la sécurité de ces pratiquants en mer tout en préservant leur autonomie et leur immersion dans l’expérience. Notre problématique est de trouver un moyen d’assurer une localisation en temps réel du sportif et de lui permettre de signaler un problème à une personne de confiance, qu’il s’agisse d’un membre de sa famille, d’un ami ou d’un membre de son club sportif, par exemple.
2. Présentation générale de la solution
La solution proposée consiste en une balise GPS conçue à partir d’un Arduino et d’un module GPS. Cette balise se fixe facilement à la bouée du pratiquant de sport en apnée (rappelons que la bouée est un équipement obligatoire). Une fois en place, elle émet toutes les minutes un signal GPS.
Ce signal peut être récupéré et consulté par un proche via un site web, accessible depuis un ordinateur ou un téléphone. Ainsi, le proche peut suivre en temps réel la position du pratiquant de sport en apnée.
De plus, cette balise est dotée d’un bouton d’alerte. En cas de situation de détresse, lorsque ce bouton est activé, un SMS contenant les coordonnées GPS est automatiquement envoyé à un numéro préalablement défini. Cela permet de transmettre rapidement une alerte avec les informations nécessaires pour localiser le pratiquant en difficulté.
3. Réalisation
3.1 Liste du matériel utilisé
- Arduino UNO
- Module Gps Gy-neo6mv2
- Powerbank 5v
- Shield SIM900 GSM/GPRS
- SIM card avec du crédit (SMS et Internet)
- Antenne
- 2 leds
- 1 protoboard
- 1 bouton cliquable
- Jumpers
- Boite plastique
3.2 Récupération de la coordonnée GPS
De gauche à droite : Arduino Uno, module SIM 900 et module GPS NEO-6M
Pour récupérer la latitude et la longitude des modules GPS NEO-6M avec Arduino, nous avons commencé par établir la connexion physique en reliant les broches VCC, GND, RX et TX du module à notre Arduino UNO. Ensuite, dans le code Arduino, nous avons configuré la communication série en utilisant la bibliothèque SoftwareSerial et nous avons défini la vitesse de communication selon les spécifications des modules (généralement 9600 bps). Dans la boucle principale du programme, nous avons lu les trames NMEA provenant des modules GPS à l’aide de la fonction readStringUntil(‘\n’) et avons stocké ces trames. Nous avons identifié les trames pertinentes contenant des données de position, telles que « $GPGGA », et nous avons analysé l’information pour extraire la latitude et la longitude. Ensuite, nous avons utilisé des fonctions pour effectuer la conversion des données, transformant les coordonnées du format NMEA en degrés décimaux. Enfin, nous avons pu visualiser ou utiliser ces données sur le port série d’Arduino. Une LED a été ajoutée pour s’assurer que notre dispositif récupère la coordonnée GPS. Elle s’allume lorsque le module GPS reçoit les coordonnées GPS.
On peut noter qu’au début du projet, nous avions le choix entre ESP32 et Arduino. Nous avons commencé avec l’ESP32, mais nous n’arrivions pas à envoyer de SMS au début, nous sommes donc passés à l’Arduino et nous avons réussi. On a donc continué le projet avec Arduino.
3.3 Schéma des branchements
Montage montrant les branchements des composants de notre balise
3.4 Transmission de la coordonnée GPS via ThingSpeak
La première idée que nous avions était de passer par Blynk qui est une application permettant de recevoir des SMS depuis le module SIM900. Cependant, c’est une application avec des fonctionnalités payante, par exemple l’affichage de la coordonnée GPS sur une carte. Nous avons donc changé de stratégie pour finalement adopter ThingSpeak et développer notre propre site web pour afficher sur une carte la coordonnée GPS.
ThingSpeak est un logiciel open source écrit en Ruby qui permet aux utilisateurs de communiquer avec des appareils compatibles avec l’internet. L’utilisation de Thingspeak se justifie par sa gratuité et par les solutions qu’il offre. En effet, cette plateforme permet de faire la liaison entre la carte arduino et Thingspeak via le réseau GPRS (internet mobile) et ensuite de faire la liaison avec un site web.
Une fois que nous avons réussi à obtenir la latitude et la longitude des modules GPS NEO-6M avec Arduino, nous avons ensuite envoyé ces données via le module GSM/GPRS SIM900. Nous avons utilisé la bibliothèque SoftwareSerial d’Arduino pour établir la communication avec le module SIM900 à l’aide de commandes AT, configurant la connexion et les paramètres nécessaires. Afin d’accéder aux données à distance et d’établir une architecture de base de données, on utilise ThingSpeak pour collecter les données envoyées depuis l’Arduino. Cela nous a également permis de gérer les requêtes API pour les envoyer ultérieurement vers un site web. Un compte ThingSpeak a été créé avec un canal ouvert, facilitant ainsi la réception des requêtes sans complication. L’adresse de ce canal est la suivante : https://thingspeak.com/channels/2345649. Deux champs ont été configurés pour enregistrer la longitude et la latitude, bien qu’il soit possible d’inclure davantage de champs pour des propositions futures. ThingSpeak offre une haute capacité de réception de données et de stockage, ce qui en fait une solution idéale pour un projet de cette nature.
Le code associé à cette fonctionnalité est disponible ici : https://git.resel.fr/deepbluetracker/website/-/tree/arduinos/Arduino?ref_type=heads
3.5 Site web dynamique
Nous avons hébergé notre site internet via le fournisseur internet de l’IMT Atlantique Brest, le ResEl, qui propose un service d’hébergement de site web. Cette solution a été choisie pour sa gratuité et pour la proximité que nous avons avec les personnes en charge de ce service.
Voici une explication de la création de ce site :
Architecture logicielle :
Notre site internet est construit autour du Framework Node.js et d’un environnement docker. Nous avons trois fichiers : ‘server.js’, ‘index.html’ et ‘style.css’ qui composent l’essentiel du site internet de notre solution. L’utilisation de docker permet un déploiement facile sur un large panel de machines, le but étant d’assurer la reproductibilité du projet.
Côté server : Node.js
Au cœur de notre back-end se trouve le fichier ‘server.js’, un fichier Node.js qui met en route notre serveur, prend en charge les requêtes et y répond. Node.js est un moteur d’exécution JavaScript qui nous permet d’exécuter des scripts côté serveur afin de créer des pages de contenu dynamiques avant que celle-ci soit envoyée au navigateur web côté client.
Les fonctions clés sont les suivantes :
- Initialiser le serveur,
- Définir les routes et les points d’accès des API,
- Gérer la logique du site internet,
- Interagir avec les services externes.
La passerelle : ‘index.html’
‘index.html’ agit comme la porte d’entrée de notre application web. C’est le premier fichier avec lequel l’utilisateur va interagir. Ce fichier définit la structure de notre page web en y incluant des liens vers les fichiers CSS et JavaScript pour améliorer l’apparence et les fonctionnalités.
Les éléments clés sont les suivants :
- Une structure HTML5 basique ‘<!DOCTYPE html>’,
- Des références to ‘style.css’ pour le style,
- Un lien vers ‘script.js’ pour les éléments intéractifs.
Styliser l’expérience : ‘style.css’
Avec ‘style.css’, nous créons l’esthétique de notre application web. Le CSS nous permet de définir le style de notre page web, s’assurant que celle-ci est non seulement fonctionnelle, mais visuellement agréable.
Les éléments clés de style sont les suivants :
- Un design s’adaptant aux différentes tailles d’écran (ordinateur, smartphone, etc),
- Des tailles, polices et couleurs customisées.
Lien vers le code (et explication rapide) et vers le site web :
Code du site : https://git.resel.fr/deepbluetracker/website
Lien du site : https://deepbluetracker.cooc.resel.fr/
Explication :
Nous allons voir plus en détail les trois fichiers principaux de notre site-web : ‘index.html’, ‘server.js’ et ‘style.css’ qui se trouvent dans le dossier ‘public’ dans le git.
‘index.html’
Le fichier ‘index.html’ définit la structure générale du site web, il se compose en deux parties principales, l’en-tête avec le titre du site et le corps qui contient le contenu du site.
Dans l’en-tête se trouvent les liens vers les fichiers de style et vers les outils qui permettent d’afficher une carte interactive.
Le corps du site est composé d’une carte interactive et d’un tableau des positions.
Une section est dédiée à la carte, un bouton s’y trouve qui permet de centrer la carte sur le dernier emplacement enregistré.
Une autre section contient un tableau destiné à afficher les détails des positions suivies, comme la date, l’heure et les coordonnées géographiques, il y a aussi une option pour choisir une date et voir les positions de la journée choisie.
À la fin de la page, il y a un pied de page avec un petit message.
Enfin, le code inclut les différents scripts qui rendent la page intéractive.
‘style.css’
Ce fichier permet de styliser et mettre en forme la page web, dans un premier temps nous réinitialiser les styles par défauts. Annuler les marges, les paddings et définir le box sizing pour plusieurs éléments HTML, l’intérêt est d’assurer une cohérence visuelle car chaque navigateur a ses propre style par défaut.
Puis nous établissons les styles généraux de la page web ‘body’ avec une police de caractères, sa hauteur et couleur, ce style est appliqué à l’ensemble du corps de la pahe.
Nous définissons également des ‘headers’ qui nous servent de titre dans la structure de notre site web, nous appliquons un espace sous le titre principal de chaque headers. De la même manière, nous ajoutons un espace autour de la section ‘main’ de la page.
Nous créons des styles pour la section de la carte ‘#map-section’ et ‘#map’ nous définissons les dimensions de la carte et les espaces entourant la section qui contient la carte.
Nous créons une section pour les pings ‘#ping-section h2’ avec un titre et des espacements et des bordures, nous faisons de même avec le sélecteur de dates ‘.data-selector’, ‘.table-container’ et ‘table’.
Pour le bouton nous appliquons un effet visuel au survol ‘:hover’ et enfin nous appliquons un effet de style sur le pied de page ‘footer’.
Pour que les effets de style soient réactifs sur mobile nous utilisons une requête média pour les ajuster (hauteur de la carte et les espacements dans le conteneur du tableau).
‘server.js’
Ce script visant à rendre la page web intéractive est découpé en plusieurs parties.
Dans un premier temps nous affichons un message dans la console afin de s’assurer que le site internet est bien lancé ‘console.log(« Le site web est chargé et prêt à fonctionner ! »);’.
Ensuite nous déclarons les différentes variables nécessaires au bon fonctionnement de la carte et la récupération des données de l’API ThingSpeak (map, maker, appDara, etc).
La première fonction que nous avons développée est ‘upadateDataFromAPI’. Cette fonction récupère les données depuis l’API ThingSpeak et les traite elle est appelée périodiquement pour mettre à jour les données. Elle met à jour la position du marqueur sur la carte sans changer le zoom ou le centrage de la carte.
La deuxième fonction développée est ‘filterPingsByDate’. Elle permet de filtrer les pings par la date sélectionnée dans le sélecteur de dates. Elle met à jour le tableau de pings avec les données filtrées.
Une autre fonction est ‘updatePingTable’ qui met à jour le tableau des pings avec les données fournies, en affichant les pings dans l’ordre décroissant de l’heure. Les heures sont ajustées au format HH:MM:SS.
La fonction ‘fillDateSelector’ remplit le sélecteur de dates avec des dates uniques et sélectionne par défaut la date la plus proche de la date actuelle. Après avoir sélectionnée la date la plus proche, cette fonction met également à jour le tableau des pings pour afficher les données correspondates.
La fonction ‘initializeMap’ initialise la carte Leaflet et la positionne sur les coordonnées du dernier ping.
La fonction ‘centerMapOnLastPing’ est appelée lorsque l’utilisateur clique sur le bouton, le zoom et le centrage sont ensuite ajustés sur le dernier ping reçu.La fonction ‘updateDataFromAPI’ est la fonction principale de notre script c’est donc cette fonction que nous appelons périodiquement avec l’instruction ‘setInterval(updateDataFromAPI, 5000);’.
3.6 Envoie SMS d’urgence
En réponse à une situation d’urgence, nous avons mis en place une fonctionnalité d’envoi de SMS d’urgence en utilisant Arduino, un bouton et le module GSM/GPRS SIM900. Lorsqu’un utilisateur appuie sur le bouton d’urgence, le code Arduino déclenche une action spécifique. Il a été nécessaire d’ajouter un numéro de téléphone destinataire auquel le message serait envoyé. À ce moment, le module GPS NEO-6M est sollicité pour récupérer instantanément la latitude et la longitude. Ces coordonnées sont ensuite intégrées dans un message d’urgence, qui inclut un lien vers Google Maps pour une localisation précise. Pour ce faire, nous avons de nouveau utilisé la bibliothèque SoftwareSerial pour communiquer avec le module GSM/GPRS SIM900 via des commandes AT.
3.7 Boîtier contenant le dispositif
Modélisations 3D de notre boitier
La boite a été imprimée à partir d’une modélisation 3D (fichier en annexe) sur une des imprimantes 3D du fablab. Elle a été faite sur mesure pour optimiser l’espace à l’intérieur. De plus, des trous permettent de faire sortir l’antenne (pour une meilleure transmission des données) et la module GPS (pour éviter d’avoir une couche supplémentaire entre lui et l’extérieur). Deux autres trous permettent de brancher l’arduino Uno et la batterie portable.
4. Résultats
4.1 Le dispositif
Une fois assemblé dans sa boite, le dispositif ressemble à ce que l’on voit sur les images suivantes :
Images montrant la boite contenant le dispositif de notre balise
Afin de le rendre étanche, nous l’avons placé dans une pochette étanche (type pochette pour téléphone), puis nous l’avons attaché à une bouée gonflable (voir image ci-dessous), qui est obligatoire lors de la pratique de chasse sous-marine, pour qu’il flotte à la surface de l’eau. De plus, étant donné la place limitée à l’intérieur de la pochette étanche, nous avons observé que le bouton était susceptible de s’activer de manière involontaire sous la pression exercée par la pochette. Afin de remédier à ce problème, nous avons ajouté un petit cylindre creux pour prévenir ce phénomène. Le bouton reste actionnable en appuyant soi-même depuis l’extérieur.
Exemple de bouée pouvant accueillir notre balise
4.2 Le site internet
Le site internet que nous avons développé est disponible sur ce lien : https://deepbluetracker.cooc.resel.fr/
On y retrouve les fonctionnalités suivantes :
- Une carte maritime interactive indiquant les différents pings du plongeur
- L’historique des pings sous forme de tableau (avec la date, l’heure, la latitude et la longitude)
- Un bouton permettant de recentrer la carte sur le dernier ping
Image du site web que nous avons developpé
4.3 Démonstration
Démonstration de notre dispositif :
4.4 Défauts
Lors de son utilisation, les critères de fonctionnement du dispositif qui font défaut au prototype sont :
- le temps qu’il faut pour obtenir la première coordonnée GPS (quelques minutes)
- la précision du module GPS. Le constructeur annonce 30 mètres mais nous obtenons une précision de 200 mètres.
5. Perspectives
Dans une perspective idéale, avec davantage de temps et de ressources, nous aurions aimé intégrer plusieurs améliorations à notre balise :
- Système attaché au nageur : Initialement, l’idée était de fixer la balise à la personne plutôt qu’à la bouée. En effet, il est ressorti des entretiens avec les pratiquants que certains chasseurs sous-marins ou apnéistes se désolidarisent parfois de la bouée (la fixant au sol avec un leste pour nager autour par exemple), ou s’en débarrassent en cas d’urgence. Cependant, la transmission des données dans l’eau posait des défis techniques trop complexes. Ce changement aurait offert une surveillance plus efficace du pratiquant de sport en apnée.
- Boîte hermétique au lieu de la pochette : Nous aurions aimé concevoir une boîte totalement hermétique spécialement conçue pour notre dispositif. Cependant, par manque de moyen et de temps, nous n’avons pas pu mettre cela en place. Il fallait trouver une solution pour rendre étanche le bouton permettant d’envoyer l’alerte par SMS.
- Amélioration de la précision du GPS et de l’actualisation de la position : Idéalement, une meilleure précision du GPS et une actualisation plus fréquente de la position auraient été souhaitables. Les coordonnées GPS que nous recevons ne sont en effet qu’assez peu précises, ce qui peut évidemment poser un problème dans le cadre d’une opération de sauvetage par exemple. Nous aurions par conséquent aimé améliorer ce point si nous avions plus de temps.
- Connexion satellitaire : Une connexion satellitaire aurait représenté une avancée significative, permettant une couverture plus large et une meilleure transmission des données même en pleine mer. Cependant, cela aurait également nécessité des moyens financiers plus importants.
- Collecte de données de santé : Intégrer la capacité de collecter et d’envoyer des données de santé telles que le pouls ou la tension faisait partie de nos idées initiales. Elle aurait permis un suivi médical en temps réel du pratiquant, ou un envoi de messages d’alertes automatiques en fonction de certains signaux vitaux spécifiques (par exemple la tension pour la syncope).
Jardin Partagé – Solution Technique
Les auteurs
Présentation de notre solution technique
Présentation du projet
Architecture globale du système
Contexte
Un jardin partagé est un jardin communautaire de quartier dont l’objectif global est axé sur le social et le partage. Ces jardins sont, pour la majorité, à l’initiative des citoyens. Malgré tout, il arrive parfois que leur création soit à l’initiative de collectivités. Dans ces cas, il peut être difficile de fédérer les citoyens, ce qui a des conséquences sur l’organisation et l’animation du jardin. De façon générale, les jardins possèdent un ou plusieurs référents qui vont gérer l’organisation, le fonctionnement et l’animation. Ces référents peuvent être animateur technique, bénévole du jardin ou animateur de mairie de quartier.
Lorsqu’aucun référent ne ressort des membres actifs du jardin, des répercussions peuvent être observées sur la planification à long terme, l’organisation et l’animation du jardin. Cela peut engendrer une perte de motivation chez les bénévoles et donc conduire à une perte du nombre d’adhérent.
Pour remédier à cette situation, nous proposons une solution qui permet à chaque membre du jardin de savoir quelles sont les tâches à faire au moment de sa visite. Également, afin de faciliter la prise de décision, notre application web est connectée à des capteurs qui permettent une supervision du jardin.
Ce projet se nomme Smart Garden et vise à améliorer et faciliter l’organisation au sein des jardins partagés de façon à ce que même les jardins sans référent puissent remplir leurs objectifs et avoir une vision sur le long terme. Nous avons recherché la simplicité et l’accessibilité en développant une interface web afin que cet outil soit accessible par tous les utilisateurs.
Solution
La solution que nous avons développée est un boîtier dans lequel est installé un système de capteurs. Cet ensemble est relié à une base de données dont les informations sont affichées sur une interface web.
Réalisation du projet
Différents outils nous ont été utiles dans la réalisation de ce projet. Afin de suivre l’avancement de notre projet, nous avons utilisé Taïga qui est un outil de gestion de projet agile. C’est grâce à cet outil que nous avons mis en place la méthode SCRUM. Dans le but de gérer les versions et la centralisation du code nous avons utilisé GIT, un système de contrôle de version open source et GitLab, une plateforme de développement collaborative open source.
Front-end
Le front-end a été fait avec la bibliothèque Javascript libre React. Notre choix s’est porté sur cette technologie car un des membres du groupe la connaissait.
Page d’accueil du site web
La page web est d’abord composée d’une entête incluant une barre de navigation permettant de passer d’une page à l’autre. Nous disposons ainsi de 3 pages : Accueil, Tâches et Fiches.
La page d’accueil
Cette page récupère avec deux requêtes GET les informations relatives aux jardins et aux relevés des capteurs afin de les afficher. Pour ce faire, nous utilisons les hooks useState et useEffect. UseState permet de stocker la donnée localement et de la modifier, nous créons alors un état local. UseEffect permet de lancer des évènements et d’en choisir les déclencheurs. Dans notre cas, UseEffect nous permet de déclencher l’appel des API lors du premier rendu de la page, soit lors de son chargement avant l’affichage. Quant à useState, il nous permet de stocker les données renvoyées par le back localement afin de les exploiter. Dans notre cas, nous nous en servons uniquement pour les afficher.
Les Fiches
Onglet Fiches
Cet onglet permet à l’utilisateur de visualiser les fiches informatives sur différents plants. Les fiches sont récupérées avec un appel d’API comme présenté dans la partie précédente. L’image est dans notre cas par défaut. Sur cette page, plusieurs interactions sont possibles et exploitent chacune différentes requêtes HTTP :
- Nous pouvons visualiser le détail d’une tâche pour obtenir les informations de la base de données concernant la fiche. Lorsque nous cliquons sur le bouton Détails, un popup recouvre la page donnant plus d’informations.
Détails d’une fiche
2. Nous pouvons ajouter une tâche en cliquant sur le bouton Ajouter et en remplissant le formulaire qui apparaît, dont tous les champs sont requis.
Formulaire d’ajout de fiche
3. Nous pouvons supprimer une tâche en cliquant sur l’icône Poubelle. Une demande de confirmation permet de limiter les risques de mauvaises manipulations.
4. L’icône à droite du nom de chaque fiche, indique la présence ou non de la plante dans le jardin. Ainsi, les tâches associées à une fiche seront affichées ou non en fonction de si la plante est sélectionnée. Il est possible de modifier cette sélection via le bouton dédié. Une fenêtre apparaît et nous pouvons modifier, sélectionner ou désélectionner les plantes avec des boutons switch. La modification n’est possible qu’après avoir cliqué sur le bouton Modifier la sélection pour éviter de mauvaises manipulations.
Sur cette page, la liste des fiches est mise à jour systématiquement à chaque modification.
Les Tâches
Onglet Tâches
Dans cet onglet, nous visualisons les tâches semaine par semaine. Elles sont de plus filtrées pour ne laisser apparaître que les tâches des fiches sélectionnées ainsi que les tâches générales. Ainsi, s’il n’y a pas de carotte dans le jardin, aucune tâche concernant les carottes n’apparaîtra.
Il est possible de naviguer d’une semaine à l’autre via les boutons Précédent et Suivant, qui modifie de +/- 7 jours la date affichée. Il est également possible de modifier directement la date en l’écrivant manuellement dans l’encadré central ou en choisissant la date en cliquant sur le calendrier.
Modification de la date via le calendrier
Comme décrit en amont pour les fiches, nous pouvons créer et supprimer des tâches. Lorsque nous ajoutons une tâche, elle s’affiche nécessairement sans être associée à une fiche. Ainsi, un référent de jardin partagé peut gérer les tâches comme il le souhaite.
Il est finalement possible de valider ou d’invalider une tâche pour savoir ce qui a été fait au sein du jardin.
Style
Le style de l’interface est dynamique afin de faciliter son utilisation. Ainsi lorsqu’un élément comme un bouton ou un onglet est survolé ou sélectionné, son style évolue pour mettre en valeur l’interaction possible.
Le style global se veut minimaliste pour ne pas perdre l’utilisateur, étant donné que nous avions établi que nos utilisateurs n’étaient pas tous à l’aise avec la technologie. Par ailleurs, l’utilisation d’un panel de vert renvoie évidemment aux végétaux.
Back-end
Le back-end de l’application se compose de trois éléments essentiels : le système d’exploitation, la base de données, et l’interface de programmation (API).
Système d’exploitation
Le cœur du système d’exploitation repose sur Docker. Docker est une plateforme qui permet de lancer des applications dans des conteneurs. L’objectif d’un conteneur est d’héberger des services sur un même serveur physique (dans notre cas nos machines personnelles) tout en les isolant les uns des autres.
Cette plateforme nous offre également un environnement uniforme pour tous les membres du projet. Cette uniformité facilite l’intégration et le regroupement des différentes composantes développées par chacun des contributeurs.
Le fonctionnement des conteneurs Docker au sein de notre infrastructure Smart Garden repose sur l’utilisation de deux composants essentiels : Docker Compose et les fichiers Dockerfile. Cette approche garantit une configuration simplifiée et une mise en œuvre efficace de l’environnement de développement.
Le fichier docker-compose.yml définit l’ensemble des services et des paramètres nécessaires à notre application. Chaque service, tel que la base de données MariaDB, l’interface PHPMyAdmin, le front-end, le back-end et le service de capteurs, est configuré de manière à interagir au sein du réseau dédié smartgarden-network. Des volumes sont utilisés pour assurer la persistance des données de la base de données, tandis que les dépendances entre les services sont gérées avec l’instruction depends_on, garantissant un démarrage ordonné.
Les fichiers Dockerfile, situés dans les répertoires ./frontend, ./backend, et ./sensor, définissent les instructions nécessaires pour construire les images Docker correspondantes. Chacun de ces fichiers permet de décrire l’environnement d’exécution, les dépendances et les étapes spécifiques à chaque composant de l’application. Ces fichiers Dockerfile sont intégrés dans le fichier docker-compose.yml pour assurer une cohérence lors du déploiement de l’ensemble de l’application.
Une fois l’application déployée dans Docker, il est possible d’accéder au front-end, à PHPMyAdmin (pour gérer et visualiser la base de données) et à la page de l’API depuis l’adresse du localhost en sélectionnant des ports dédiés. Ces ports sont configurés dans le fichier docker-compose.yml, les fichiers Dockerfile et parfois les fichiers de configuration des services.
Base de données
Pour la gestion des données, nous avons opté pour MariaDB, un système de gestion de base de données relationnelles. Cette solution est complétée par l’utilisation de PHPMyAdmin, une interface web qui simplifie la manipulation et la visualisation des données stockées.
PHPMyAdmin nous a principalement été utile au début du projet afin de mettre en place les premières versions des bases de données. Cet outil nous a permis de faire de nombreux tests avant que l’API ne soit disponible dans l’application.
Dans ce projet nous avons pensé à une base de données simple. Voici le schéma de la base de données :
Diagramme UML de la base de données
API
L’interface de programmation (API) repose sur FastAPI, un framework Python moderne et performant. Le serveur Python s’interface avec la base de données et expose des points d’accès pour la gestion des différents éléments nécessaires dans le site web (front-end).
FastAPI utilise la librairie Pydantic pour définir les modèles de données, facilitant ainsi la validation des données entrantes et sortantes. Chaque point d’accès est défini comme une fonction asynchrone associée à une route particulière. Chaque entité (Jardin, Parcelle, Action, etc.) dispose de points d’accès spécifiques pour la création, la lecture, la mise à jour et la suppression des données.
En résumé, notre API FastAPI offre un ensemble de points d’accès structurés pour la gestion des données de notre application Smart Garden et les modèles Pydantic garantissent la validité des données.
Un serveur Python fonctionne en parallèle avec un script Python dédié à la récupération des relevés des capteurs à partir du protocole MQTT. Ces données sont ensuite intégrées de manière transparente dans la base de données, assurant ainsi une mise à jour constante et en temps réel.
Schéma représentant les interactions entre les services
Capteur
Cette partie est dédiée à la mise en place du module électronique qui va permettre de prélever les données du jardin en temps réel. Le traitement de ces données en aval du système électronique va permettre de générer les tâches à effectuer dans le jardin.
Pour cela, nous allons d’abord présenter l’objet lui-même et les éléments intervenants à sa mise en place. Puis nous allons présenter l’architecture globale assurant la communication entre cet objet et la partie Back-end du projet.
Matériels utilisés
Divers matériels et/ou matériaux ont été utilisés dans la réalisation du projet:
- Une carte électronique Lopy 4
- Une antenne
- 2 capteurs d’humidité du sol Funduino
- Un capteur de température DHT11
- Des câbles mâles-femelles et mâles-males
- Une batterie portable de 5 volts
- 10 cm de plastique thermorétractable
- 1 Planche de bois 3 cm x 20 cm
- 2 Vis pour fixer la capteur de température à la planche
- 1 Récipient en plastique rempli de terre
Conception du boîtier
Nous avons choisi de concevoir le boîtier qui abritera notre dispositif électronique à l’aide du logiciel Tinkercad. Les dimensions de cette boîte dépendent de la largeur de la carte Lopy 4 et de la longueur de la batterie connectée à l’intérieur. La boîte aura des dimensions de 20×14 cm et incorpore un couvercle coulissant avec des arêtes diagonales pour obtenir une fermeture quasi-parfaite et fournir une protection efficace.
Le fichier de conception Tinkercad.
Une fois que le boîtier a été imprimé grâce à l’imprimante 3D du FabLab, nous sommes passés à la phase de post-production pour assurer la fonctionnalité et la connectivité optimale du dispositif. À cet effet, différents outils spécialisés ont été utilisés afin de réaliser des perforations précises dans le boîtier. Ces perforations ont été effectuées de manière stratégique pour loger et connecter l’antenne, garantissant ainsi une réception de signal efficace. De plus, des ouvertures spécifiques ont été créées pour faciliter l’exposition des capteurs d’humidité du sol et du capteur de température DHT11 à l’environnement extérieur.
Schéma électrique du câblage
La connexion entre la carte Lopy 4 et les capteurs s’établit comme suit :
Les capteurs d’humidité du sol, de température et d’humidité relative de l’air sont des composants essentiels dans une solution IoT (Internet des objets) conçue pour la surveillance des espaces verts. Ces capteurs jouent des rôles clés en fournissant des données environnementales permettant une gestion efficace et durable des espaces verts, que ce soit dans des jardins partagés, des parcs urbains ou des espaces communautaires.
– Capteur d’humidité du sol :
Description : Ce capteur mesure l’humidité du sol, indiquant la quantité d’eau présente dans la zone de culture.
Importance : Il facilite la surveillance de l’humidité du sol, permettant des ajustements précis dans l’irrigation. Un niveau optimal d’humidité est essentiel pour la croissance saine des plantes et des cultures.
Avantages IoT : L’intégration de ce capteur dans une solution IoT permet la surveillance à distance et en temps réel de l’état du sol.
– Capteur de température et d’humidité relative de l’air :
Description : Ce capteur mesure à la fois la température ambiante et l’humidité relative de l’air environnant.
Importance : Il fournit des données cruciales sur les conditions climatiques, qui sont fondamentales pour la croissance et le développement des plantes. Il aide également à identifier des situations qui pourraient affecter la santé de la végétation.
Avantages IoT : La connexion IoT permet la collecte et l’analyse continue des données climatiques. Cela permet la mise en œuvre de stratégies proactives, telles que des alertes automatiques en cas de conditions climatiques extrêmes.
– Communication entre la lopy 4 et les capteurs
Pour assurer la communication avec les différents capteurs, nous avons élaboré un script python qui est disponible depuis le dépôt GitLab [lien du code].
Architecture globale de la communication
–Communication via LoRa
LoRa, acronyme de Long Range, est un protocole de communication sans fil qui se distingue par sa capacité à transmettre des petits paquets de données (0,3 kbps à 5,5 kbps) à un récepteur sur de longues distances avec une consommation d’énergie remarquablement basse depuis un émetteur (node) . La couverture LoRa peut s’étendre sur plusieurs kilomètres, s’adaptant aux environnements urbains et ruraux.
Les données émises par les capteurs sont transmises à la passerelle (gateway) LoRa qui peut gérer des centaines de nœuds LoRa en même temps. Dans notre cas, nous nous sommes servis de la passerelle Indoor (Rayon de 100m) du Fablab de l’IMT Atlantique.
–Communication via WiFi
Le protocole WiFi sera utilisé pour la transmission des données entre la passerelle LoRa et le serveur d’application contenu dans la plateforme The Things Network (TTN). Il faut noter que la passerelle LoRa est alimentée par le secteur et connectée à internet via le réseau 4G/5G. Dans notre cas, la passerelle était connectée au réseau local, lui-même connecté à internet.
–Communication via MQTT
MQTT est un protocole adapté aux objets contraints qui fonctionnent selon l’architecture publish and subscribe. Cette architecture est orchestrée par un broker (MQTT broker) qui est déjà implémenté sur la plateforme TTN. Nous avons implémenté le client MQTT via le langage de programmation python en utilisant la librairie paho-mqtt [Lien du code d’implémentation]. C’est ce client qui va se connecter au cloud TTN afin de récupérer les données de nos capteurs en souscrivant au nœud LoRa adéquat et en choisissant la QoS (qualité de service) appropriée selon le projet.
Avant d’utiliser la librairie paho-mqtt de python, nous avons d’abord tenté d’utiliser Node-RED, un outil d’automation de flux permettant de contrôler et d’interconnecter des services cloud ou des objets connectés entre eux. La connexion à la plateforme TTN via le protocole MQTT et l’extraction des données s’est faite sans problème. Mais, comme nous avions hébergé Node-RED sur Docker, pour un travail plus collaboratif, la création ou la modification d’un flux sur Node-RED n’était pas mis à jour chez tous les membres du groupe. Cela nous obligeait à mettre à disposition un ordinateur central faisant tourner le script. Par conséquent, nous nous sommes tournés vers l’élaboration d’un script python. Il nous a permis de connecter le client MQTT au broker de la plateforme TTN afin de récupérer et d’envoyer les données à la base de données. Rendant ainsi le code accessible à tous via GIT.
Perspectives
De nombreuses améliorations sont possibles pour notre solution. La principale est d’intégrer le script des capteurs dans Docker, c’est-à-dire, faire le lien entre le backend (API) et la plateforme TTN pour exploiter les données relevées. Actuellement, le script n’étant pas inclus dans le container Docker, il fonctionne indépendamment du projet.
De plus, la génération automatique de tâche, en exploitant les données des relevés de capteurs, apporterait de la valeur aux utilisateurs.
D’autres améliorations mineures optimiseraient l’expérience utilisateur :
- Gérer l’authentification des jardins
- Ajouter une vue calendaire offrirait une vision long terme pour les utilisateurs
- Personnaliser les fiches avec l’ajout d’image et le stockage dans la base de donnée
- Améliorer les formulaires (pour permettre d’associer les tâches aux fiches par exemple)
- Ajouter des données météorologique afin de les comparer aux tâches (la pluie influant sur le besoin en arrosage par exemple)
- Améliorer le design du boîtier de sorte à le rendre plus ergonomique en ajoutant des trous pour indiquer l’état du fonctionnement de notre dispositif (marche, arrêt, état de chargement de la batterie).
Conclusion
Le projet Smart Garden représente une réponse innovante et technologique aux défis rencontrés par les jardins partagés, notamment en l’absence de référents. Nous avons ainsi mis en place une solution complète, allant d’une interface web simplifiée à la création d’un système de capteurs, dans le but de d’améliorer la gestion quotidienne des espaces communautaires.
Bien que de nombreuses fonctionnalités soient déjà opérationnelles, notre solution pourrait être approfondie en intégrant notamment l’automatisation de la génération de tâche, en particulier en exploitant les données des capteurs.
Annexes
Lien vers le dépôt GitLab : ici
Lien vers la vidéo de démonstration : ici
