Disques des fractions et des pourcentages

Envoyé par m22tourn le 15 Mar 2024 dans Projets | 0 commentaire

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).

Fichier fractions

Fichier pourcentages

boite de rangement

Puzzles êtres vivants

Envoyé par m22tourn le 5 Mar 2024 dans Projets | 0 commentaire

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.

Fichier svg du mandrill

Fichier svg de la grenouille

DeepBlue Tracker – Solution technique

Envoyé par c23leric le 15 Jan 2024 dans Projets, TAF COUAD | 0 commentaire

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

 

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

 

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

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 : 

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.

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

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

Envoyé par s23kango le 15 Jan 2024 dans Projets, Blog, TAF COUAD | 0 commentaire

Les auteurs

 

 

Présentation de notre solution technique

 

Présentation du projet

Réalisation du projet

Perspectives

Conclusion

Annexes

 

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.

[Lien de la vidéo]

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 :

1. 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

RiverCleaner – solution technique

Envoyé par a22gomes le 15 Jan 2024 dans Projets, TAF COUAD | 0 commentaire

 

22/12/2023

Auteurs:
Anna Terra GOMES GUERRA, Mathieu BOURGES, Dely Catalina ARDILA MEDINA

TABLE DES MATIÈRES

1. Introduction
   1. Objectif du projet (et les domaines/technologies qu’il couvre)
   2. Spécifications du projet
      1. Diagramme de cas d’utilisation
   3. Diagramme de blocs d’architecture
2. Hardware
   1. Conception 3D
   2. Conception dans la découpeuse laser
   3. Environnement de test
      1. Liste matériel pour configuration
   4. Électronique (RiverCleaner)
      1. Liste du matériel
      2. Parlons bien, parlons code
3. Software
   1. Serveur TTN
   2. Serveur base de données
   3. Monter un serveur WEB
      1. Setup de la raspberry
      2. Apache2
      3. Installation de php
      4. Installation du serveur de base de donnée
      5. phpMyAdmin, notre interface pour configurer la base de données
      6. Mise en place des utilisateurs
      7. Installation de la base de donnée
      8. Installation du site web
      9. Création de l’API MQTT de TTN
      10. Setup python sur la raspberry
      11. Script pour la récupération des données en MQTT sur la raspberry
   4. Page Web 25
      1. Fonctionnalités
4. Perspectives et conclusiones
   1. 1. Perspectives

    

   1. 1. Conclusions

    

I. Introduction

A. Objectif du projet (et les domaines/technologies qu’il couvre)

Conception d’un modèle novateur de système de collecte des déchets flottants dans les rivières, conçu pour atténuer la pollution de l’eau avant d’atteindre l’océan. Ce système intègre des bouées rotatives élégantes qui dirigent avec habileté les déchets flottants vers un conteneur intelligent connecté via la technologie LoRa. Cette solution contribue non seulement à la préservation de l’environnement, mais recueille également des données précieuses dans une base de données, offrant un accès aisé pour les futures recherches et observations. De plus, elle propose une expérience interactive via une page web conviviale, permettant aux utilisateurs de visualiser de manière intuitive l’état du système grâce aux lectures précises des capteurs, soulignant ainsi notre engagement envers un avenir plus propre et durable.

 

 

B. Spécifications du projet

a. Diagramme de cas d’utilisation

 

 

Ce schéma met en lumière les caractéristiques mises en œuvre par le système et les divers acteurs associés à ces actions. Les acteurs clés qui interagissent comprennent les responsables du système de bouées, les citoyens et les responsables des déchetteries. Les responsables des bouées initient les interactions en évaluant l’adéquation environnementale, les citoyens jouent un rôle prépondérant dans le processus d’entretien du système et dans la collecte manuelle des déchets, tandis que les responsables des déchetteries se chargent du traitement des déchets au-delà des responsabilités du citoyen ordinaire. Cette collaboration dynamique entre ces acteurs crée un écosystème efficace pour la préservation de notre environnement.

 

C. Diagramme de blocs d’architecture

Ce schéma offre un aperçu captivant de la conception du système et des interconnexions qui le caractérisent. Il met en lumière les flux de données entre les capteurs, la carte Arduino avec son module Lora Groove Wio E5, les serveurs dédiés au traitement et au stockage des données, ainsi que le site Web permettant une visualisation aisée. Il illustre également le cheminement des déchets flottants, depuis les bouées rotatives jusqu’au conteneur à ordures interconnecté.

 

En résumé, ce schéma offre une vision claire des interactions entre les éléments clés du système, mettant en avant les flux de données et de déchets qui facilitent le fonctionnement harmonieux du système de collecte des déchets flottants RiverCleaner.

 

II. Hardware

A. Conception 3D

Voici une représentation 3D immersive des 3 bouées tournantes, vue sous différentes perspectives pour une appréciation maximale.

 

 

Pour la conception de la bouée rotative, l’inspiration a été puisée d’un projet existant sur https://rivercleaning.com. Le modèle a été adapté aux exigences spécifiques du système, en tenant compte des caractéristiques uniques de notre environnement d’essai. Ainsi, la décision a été prise d’équiper la bouée de pales de ventilateur pour optimiser sa rotation selon le flux d’eau des rivières, avec un diamètre réfléchi à 80 mm pour s’intégrer harmonieusement à l’environnement environnant.

De manière similaire, trois de ces bouées ont été déployées pour assurer un acheminement continu des déchets flottants vers le panier à ordures. Ces bouées sont fixées au fond grâce à un axe adaptable, offrant une flexibilité d’implémentation qui permet non seulement le passage aisé de petits bateaux si nécessaire, mais aussi le respect de la vie marine des rivières. De plus, leur adaptabilité au niveau de l’eau, sujet à des variations fréquentes au fil du temps, renforce leur efficacité dans des conditions changeantes. Cette approche ingénieuse garantit une solution robuste et adaptable pour la collecte efficace des déchets flottants.

 

B. Conception dans la découpeuse laser

Voici la conception innovante des faces du panier à ordures, pensée avec des filtres et des tiges pour garantir la rotation fluide des bouées au sein de notre environnement de test :

 

 

Initialement conçue comme une poubelle parfaite de 90x90x90 mm, la conception du panier à ordures s’est réduite au fil du processus à la mise en œuvre de seulement 4 faces, dont l’une arbore un filtre en forme de poisson pour injecter de la personnalité dans le projet et renforcer l’image de la marque. Deux barres de 14 x 274,5 mm ont été ingénieusement intégrées en tant que poutres, maintenant les bouées rotatives pour optimiser l’utilisation du matériau et assurer une adaptabilité accrue à l’environnement. Cette approche créative ajoute non seulement du caractère au projet, mais renforce également l’esthétique globale et l’attrait visuel de la marque. 

En outre, à la suite de tests visant à affiner le système de collecte des déchets, une décision innovante a été prise de remplacer l’arrière du conteneur par une structure en maille imprimée en 3D avec des trous de 6 mm x 6 mm et un espacement de 2 mm entre eux. Cette modification est conçue pour favoriser une circulation optimale de l’eau tout en améliorant la rétention des déchets dans le système.

 

 

C. Environnement de test

a. Liste matériel pour configuration

• 1 grand conteneur
• 1 Pompe à eau
• 1 mur de séparation
• Supports pour panier à ordures
• Fil de fer
• Ruban isolant
• Eau

 

 

Pour la mise en œuvre de l’environnement de test, nous avons choisi un grand récipient d’eau, dans lequel une pompe à eau a été stratégiquement installée pour créer un courant simulé, imitant l’écoulement d’une rivière. En outre, un mur de séparation a été placé au centre du conteneur afin d’assurer une circulation uniforme autour de celui-ci. Cette disposition intelligente empêche tout croisement inattendu des courants, évitant ainsi tout comportement indésirable des bouées, comme des virages inattendus ou des interruptions du mouvement cinétique. Cette configuration permet une simulation réaliste et contrôlée, créant un environnement d’essai idéal pour évaluer les performances du système. Pour fixer les bouées au modèle, nous avons choisi d’utiliser des fils moulables, en les faisant passer verticalement à travers les bouées, et un fil horizontalement pour assurer la stabilité, comme l’illustrent les images. Étant donné la proximité de ces fils avec l’eau, nous avons appliqué du ruban isolant à titre préventif afin d’éviter tout problème futur.

 

 

D. Électronique (RiverCleaner)

a. Liste du matériel

• 1 Module Lora Grove Wio E5
• 1 Arduino Leonardo
• 1 Capteur de niveau d’eau
• 1 Détecteur de distance à ultrason.
• 1 Arduino Grove Base Shield

Chacun de ces modules occupe un rôle clef dans le projet : 

• Le capteur à ultrason, va détecter quand la poubelle est pleine
• Le capteur de niveau d’eau, va nous donner des informations sur le niveau de la rivière (si il est supérieur ou inférieur à la normale)
• Le buzzer, va fournir une information sonore sur l’état du système
• Le LoRa-E5, va nous permettre d’envoyer les données en LoRa sur un serveur.

 Vous trouverez ci-dessous le schémas de montage du système :

 

 

Sur le port UART, nous retrouvon le module LoRa-E5

Sur le port D6, se trouve le Buzzer

Sur le port D7, le détecteur à ultrason (Ultrasonic Ranger)

Sur le port I2C Droit, se trouve le capteur de niveau d’eau

 

b. Parlons bien, parlons code

Notre projet est fait sur arduino, nous avons donc développé notre code sur cette plateforme. L’ensemble du code du projet se trouve sur un gitlab hébergé sur les serveurs de IMT Atlantique. Le gitlab est disponible en suivant ce lien dans la section arduino : https://gitlab.imt-atlantique.fr/m21bourg/rivercleaner
Plusieurs remarques sont à faire à cette étape :

• Assurez-vous d’avoir une Arduino Léonardo. LE CODE NE FONCTIONNE PAS POUR D’AUTRE TYPES DE CARTES !!!!
• Assurez-vous d’avoir une liaison série entre le PC et la carte. Le programme ne se lancera pas tant qu’il n’aura pas réussi à établir une liaison série. (Vous pouvez shunter cette sécurité en commentant la ligne 55 “while (!USB_Serial);” ).

 

• Dans le fichier config_application.h Changez le DevEUI (mettez celui qui vous est fourni par TTN)
• Dans le fichier config_application.h Changez l’AppKey (mettez aussi celui qui vous est fourni par TTN)

 

 

III. Software

A. Serveur TTN

Pour établir la connexion avec le serveur TTN, il est impératif de créer un « End device », dans notre cas, le module Lora Grove Wio E5, chargé de communiquer les données lues par la carte Arduino avec The Things Network.

 

 

Cette démarche permet d’obtenir les informations d’identification essentielles pour une connexion réussie et une lecture correcte des données récupérées. Ultérieurement, ces données servent également à établir des liens entre les bases de données et les serveurs qui interagissent de manière transparente avec l’utilisateur. Ce processus garantit une intégration harmonieuse et efficace des données dans l’écosystème du projet.

 

 

 

B. Serveur base de données

Dans cette étape cruciale, les données capturées sont méticuleusement archivées dans une base de données, offrant ainsi la possibilité de les consulter en fonction de divers paramètres tels que la date, l’heure, la quantité de déchets, le niveau d’eau, et bien d’autres. Cette approche réfléchie permet une analyse approfondie et une visualisation personnalisée des informations, fournissant ainsi une compréhension holistique des tendances et des schémas liés à la gestion des déchets flottants.

Pour le serveur de base de données, nous avons fait le choix d’utiliser un serveur mySQL. Ce choix présente plusieurs avantages :

• Facilité de mise en place
• Bonne gestion d’une grosse quantité de donnée
• Facilité de lien avec différents autres services

La base de donnée est construit sur le schémas suivant :

 

 

user désigne les utilisateurs. Un utilisateur est représenté par :

• Un ID (numéro d’utilisateur)
• Name (un nom)
• Firstname, un prénom
• Password (un mot de passe)

tool désigne l’outil riverCleaner. Il est représenté par :

• Un ID
• Location, la localisation de la station
• LoRa address : L’adresse LoRa pour contacter l’outil
• River name : le nom de la rivière ou l’outil est installé

Etant donné qu’un utilisateur peut avoir un ou plusieurs outils nous avons une table de liaison “haveTool” qui fait le lien entre user et tool.

Enfin, vu qu’un outils peut faire des mesures, nous avons une table measurement qui contient l’ensemble des mesures des outils, une mesure est décrite par :

• Un ID
• L’identifiant de l’outil qui à fait la mesure
• State : désigne l’état du système
• Full : un boolean qui indique si la poubelle est pleine ou non
• Water_level : donne une information sur le niveau d’eau de la rivière
• Date : horodatage de la mesure (créé automatiquement par la base de donnée).

 

C. Monter un serveur WEB

Matériel :

• Raspberry PI 4 B+
• Carte micro SD (4 Go minimum requis)
• Moniteur, clavier, souri, connexion internet

 

a. Setup de la raspberry

Dans un premier temps, nous allons préparer la raspberry. Pour cela nous allons avoir besoin d’un OS. Dans un premier temps, allez chercher une Image sur le site de raspberry (https://www.raspberrypi.com/software/operating-systems/ ). Pour vous faciliter la tâche, je vous recommande une image Raspberry Pi OS with desktop and recommended software. Bien qu’elle soit plus grosse, elle dispose de quelques outils pré-installés, qui vous aideront lors du débugage. 

Flashez la carte SD avec l’image de Raspberry PI OS avec l’outil de votre choix (je vous recommande balena Eatcher https://etcher.balena.io/ ). 

Une fois la carte SD flashée, insérée la dans la raspberry, et mettez le système sous tension. Au bout de quelques minutes, vous devriez arriver sur l’outil d’aide à l’installation.

Si cela ne fonctionne pas : 

• Vérifiez que le moniteur est sous tension, et qu’il a la bonne source
• Vérifiez la présence de fichier sur la carte SD (vous avez peut-être flasher autre chose, comme une clef USB)
• Vérifiez que vous avez bien flasher un image de raspberry pi OS (non de Raspberry Pi OS for VM)

Suivez le guide d’installation, et faites les éventuelles mise à jour. Une fois la raspberry complètement installée, redémarrez la.

 

b. Apache2

Nous allons maintenant passer à la configuration de la raspberry afin de la transformer en serveur web.

Tapez ‘sudo /etc/init.d/apache2 restart’. Si vous avez un message de redémarrage, vous pouvez passer à l’étape de l’installation de php.

Sinon, nous allons installer manuellement le serveur apache.

Tapez ‘sudo apt install apache2’ Cette commande va installer un serveur apache (eq serveur web html) sur la raspberry.

Afin de vérifier si le serveur est bien installé, ouvrez un navigateur, et tapez dans la barre de recherche ‘localhost’ ou ‘127.0.0.1’. Vous devriez arriver sur une page comme celle-ci :

 

Si ce n’est pas le cas :

• Faites une MAJ sur la carte (‘sudo apt-get update’ puis ‘sudo apt-get upgrade’, puis reboot)
• Tentez de réinstaller le serveur (‘sudo apt-get install apache2’)
• Essayez la commande ‘/etc/init.d/apache2 restart’
• demandez à chatGPT de l’aide

 

c. Installation de php

Nous allons maintenant passer à l’installation de php.

Dans votre terminal, tapez la commande ‘sudo nano /var/www/html/example.php’.

Une fenêtre devrait s’ouvrir. Entrez les lignes de code suivantes : 

<!DOCTYPE html>
<html>
              <?php
                           print(“<h1>HELLO WORLD !!!!</h1>”);
               ?>
</html>

Dans votre navigateur, dans la barre d’adresse, tapez ‘localhost/example.php’. Si vous observez un HELLO WORLD !!!! marqué en très gros. Vous pouvez passer à la partie installation du serveur sql.

Si vous avez une erreur, vous avez sans doute mal recopié le code donné ci-dessus. Vérifiez bien la présence de “;” à la fin de la ligne de code. 

Si vous avez seulement une page balance, cela signifie que php n’est pas installé sur la raspberry.

Nous allons installer php à la main. Pour cela, tapez la commande ‘sudo apt-get install php’. Cette commande devrait installer automatiquement la dernière version de php. Confirmez cela en regardant la version de php (‘php -v’). Réessayez de charger la page “localhost/example.php”.

Cela ne fonctionne toujours pas : 

• Vérifiez l’URL
• Redémarrez le serveur apache “/etc/init.d/apache2 restart”
• Redémarrez la raspberry
• Renseignez vous sur internet

 

d. Installation du serveur de base de donnée

Les étapes qui vont suivre sont un peu plus complexes. Je vous recommande de suivre les documentations en ligne.

Nous allons passer à l’installation du serveur de base de données mysql. Pour cela tapez la commande ‘sudo apt-get install mysql-server’. Cette commande va permettre d’installer un serveur mysql sur la raspberry. Bien que dans une certaine mesure c’est mieux, je vous déconseille de faire la sécure installation de mysql, cela peut bloquer votre base de donnée, et vous serez obligé de flasher à nouveau la carte SD. 

Afin de vérifier sa bonne installation, tapez la commande ‘sudo mysql’. 

Si vous avez ce message (à quelques différences près), félicitation, vous avez un serveur SQL, vous pouvez passer à l’installation de phpmyadmin.

Afin de sortir du terminal mysql tapez la commande exit.

Si la commande ne fonctionne pas, regardez la documentation en ligne.

 

e. phpMyAdmin, notre interface pour configurer la base de données

Une fois votre base de données installée, nous allons procéder à l’installation de l’outil qui va la gérer : phpMyAdmin.

Pour cela, tapez la commande ‘sudo apt-get install phpmyadmin’. 

Dans un premier temps phpmyadmin vous demandera des accès à la base de donnée faites Entrée pour accepter

Ensuite, il vous demandera quel serveur web nous souhaitons reconfigurer. Faites ESPACE afin de sélectionner apache2, et appuyer sur Entrée

Normalement c’est tout bon. Allez sur la page de connexion de phpmyadmin en tapant dans votre navigateur ‘localhost/phpmyadmin/’
Si vous avez une page qui ressemble à cela, vous avez réussi à setup phpmyadmin :

Si cela ne fonctionne pas : 

• Redémarrez apache ‘/etc/init.d/apache2 restart’
• Redémarrez la raspberry
• Cherchez dans la documentation en ligne (https://pimylifeup.com/raspberry-pi-phpmyadmin/)

 

f. Mise en place des utilisateurs

Dans cette étape, nous allons mettre en place les utilisateurs de la base de données. 

Tapez ‘sudo mysql’ Vous devriez ouvrir un terminal mysql.

Ensuite tapez la commande : 

CREATE USER ‘[username]’@’localhost’ IDENTIFIED BY ‘[password]’;

Remplacez [username] par un nom d’utilisateur ex :  ‘user’@’localhost’
Remplacez [password] par le mot de passe de votre choix ex : ‘password’
N’oubliez pas le “;” à la fin de la requête.

Ensuite, nous allons attribuer des droits à cet utilisateur. Pour cela tapez la commande :

GRANT ALL PRIVILEGES ON *.* TO ‘[username]’@’localhost’ IDENTIFIED BY ‘[password]’ WITH GRANT OPTION;

Remplacez [username] par un nom d’utilisateur ex :  ‘user’@’localhost’
Remplacez [password] par le mot de passe de votre choix ex : ‘password’
N’oubliez pas le “;” à la fin de la requête.

Retournez sur la page de connexion de phpmyadmin et entrez le couple login mot de passe que vous venez de créer. (utilisez [username] pour le login, pas besoin du @’localhost’)

Si vous êtes connecté, félicitation ! Vous avez phpmyadmin à votre disposition.

Sinon : 

• Vérifiez que vous avez bien le bon couple login mot de passe
• Redémarrez apache2 ‘sudo /etc/init.d/apache2 restart’
• Redémarrez la raspberry
• Cherchez de l’aide en ligne

 

g. Installation de la base de donnée

Nous allons maintenant passer à l’installation de la base de données. 

Dans un terminal tapez ‘sudo mysql’

Puis  : CREATE DATABASE riverCleaner;

Cette commande va créer une base de donnée dans le serveur mysql.

Retournez dans phpmyadmin et retrouvez la base de donnée rivercleaner, cliquez dessus (cela permet de la sélectionner) et importez la base de donnée river cleaner disponible sur le gitlab : https://gitlab.imt-atlantique.fr/m21bourg/rivercleaner

Maintenant, vous avez une base de données pour votre projet !

 

h. Installation du site web

Mettez sur une clef USB le code du site web disponible sur le gitlab https://gitlab.imt-atlantique.fr/m21bourg/rivercleaner

Sur la raspberry, déplacez le fichier ‘WEB’ sur le bureau

Dans un terminal taper la commande suivante : 

sudo cp -R ./Desktop/WEB/ /var/www/html/

Cette commande à pour effet de copier le dossier WEB et le coller dans le dossier /var/www/html

Dans un navigateur recherchez l’adresse ‘localhost/WEB/’. Vous devriez arriver sur la page d’accueil de riverCleaner.

Notre objectif est maintenant de réaliser le montage suivant :

 

Pour cela, nous allons avoir besoin de créer un lien entre la base de données et le serveur SQL. Cela va se faire en deux temps. Dans un premier temps nous allons faire en sorte que le serveur nous envoie les informations, puis nous allons les récupérer avec un code python

 

i. Création de l’API MQTT de TTN

Nous allons maintenant créer l’API MQTT qui servira à récupérer les informations émises en LoRa par la carte arduino. 

Pour cela connectez vous à TTN. Dans application -> tp-lora-cooc -> MQTT.

Cliquez sur “generate new API key”. Ceci va générer une clef API pour que l’on puisse se connecter en MQTT à l’ensemble du service “tp-lora-cooc”. Notez bien aussi le username “tp-lora-cooc@ttn”, celui-ci nous sera très utile pour la suite.

 

j. Setup python sur la raspberry

Pour commencer, installons pythons sur la raspberry : 

sudo apt-get install python3-full

C’est une version plus complète de python (qui intègre un peu plus d’outils dès le départ).

Ensuite nous avons besoin d’installer différentes librairies : 

• paho-mqtt -> permet de recevoir des flux en MQTT
• mysql-connector -> qui permet de s’interfacer facilement avec la base de donnée

Vous pouvez les installer facilement avec pip : 

pip install paho-mqtt
pip install mysql-connector

Si cela ne fonctionne pas : 

• Redémarrez la raspberry (surtout si vous venez tout juste d’installer python)
• Renseignez vous sur les problème de virtual environnement (les .venv)
• Téléchargez pip (le script get-pip.py disponible sur le site officiel de pip fonctionne bien)
• Regardez la documentation en ligne

 

k. Script pour la récupération des données en MQTT sur la raspberry

Nous allons pouvoir installer le script qui permet de faire la liaison entre le serveur TTN et la base de données SQL. Dans un premier temps récupérez le script python disponible sur le gitlab : https://gitlab.imt-atlantique.fr/m21bourg/rivercleaner.

Mettez les valeurs adéquat pour lier votre raspberry au serveur TTN.

Et à la fin du document remplissez les champs avec vos informations de connexion avec la base de données :

Une fois ceci fait, vous pouvez exécuter le script python avec la commande : 

python3 [VotreScript].py
ou [VotreScript] est le nom de votre script.

Si vous recevez des informations sur votre serveur, celles-ci seront automatiquement transmises dans le terminal, et si elles sont compatibles, elles iront dans la base de données.

 

D. Page Web

a. Functionnalités

La page web permet à l’utilisateur d’avoir une vue sur son système. Combien de polluants, il a retiré de la rivière, l’état du système, …

La page web est hébergée sur un serveur apache. Elle est liée à la base de données. La page web dispose aussi d’une API sur laquelle les scientifiques peuvent se connecter afin de recevoir des mesures des différents outils.

Bien que nous n’ayons pas eu le temps de mettre en place l’API, nous avons pu commencer à travailler sur le site web. Le site web à un front-end en html, un backend en php et bootstrap 3 pour toute la partie “CSS”.

Le site est composé de plusieurs pages : 

• Page d’accueil
• Page de relevé des mesures
• Page de création de compte
• Page de login

La page d’accueil regroupe différentes informations sur ce qu’est le projet riverCleaner, ce qu’il fait, à quoi il sert … 

La page de relevé des mesures, se contente d’afficher les mesures présentes dans la base de données. A terme, le but sera d’afficher les mesures relatives à un utilisateur, avec des options de filtrage (filtrer par appareil, filtrer par date, …)

Page de création de compte. Cette page sert à se créer un compte riverCleaner. Elle prend comme entrée Nom, Prénom et mot de passe. Il est possible de faire de l’injection de code dans la page.

Page de login, cette page sert juste à se logger sur le site. Pour l’instant elle affiche juste un message pour indiquer que l’authentification à réussi, mais à terme, il faudra mettre les mécanismes de session PHP, pour garder l’authentification.

function.php est un fichier central dans ce site. Il permet de centraliser des fonctions php communes au site web. Par exemple, il centralise les fonctions relatives au header, footer, navbar, connexion à la base de données, imports bootstrap … Si vous souhaitez récupérer le site, vous devrez passer un peu de temps pour comprendre ce fichier. 

 

IV. Perspectives et conclusiones

A. Perspectives

Les perspectives d’avenir de ce projet sont prometteuses. La technologie utilisée pour collecter les déchets flottants dans les rivières pourrait être adaptée à d’autres applications, notamment dans les grandes rivières. En outre, l’ajout de fonctionnalités, telles que la détection de la qualité de l’eau ou la surveillance de la faune, pourrait encore améliorer l’efficacité et l’impact environnemental du système. Enfin, la collaboration avec les autorités locales et les organisations environnementales pourrait permettre d’étendre le système à une plus grande échelle, contribuant ainsi à la préservation de l’environnement à l’échelle mondiale.

B. Conclusions

En conclusion, ce projet de collecte des déchets flottants dans les rivières représente une avancée significative dans la lutte contre la pollution de l’eau. La combinaison de la conception innovante des bouées rotatives, de l’utilisation de capteurs avancés et de la mise en place d’une infrastructure logicielle solide démontre l’efficacité de l’approche multidisciplinaire adoptée. Ce système offre une solution pratique et adaptable pour la collecte efficace des déchets flottants, tout en fournissant des données précieuses pour des recherches futures. Il incarne l’engagement envers un environnement plus propre et durable, tout en ouvrant la voie à de nouvelles possibilités d’amélioration et d’expansion.

PharmaBox – Solution Technique

Envoyé par a21derri le 15 Jan 2024 dans Projets, TAF COUAD | 0 commentaire

Auteurs

Fred NGUETTA

Michael MORENO

Romain BOINET

Adam GIOVANNI

Alexandre DERRIEN

Contexte

Au sein de la spécialité Conception d’objets communicants à IMT Atlantique, nous réalisons un projet innovant répondant à un besoin réel. Dans notre équipe, le secteur de la santé est tout de suite apparu comme un domaine qui méritait notre attention. Nous avons en effet constaté grâce à nos entourages et différents entretiens que le métier d’infirmière était sujet à une forte surcharge de travail dûe à un emploi du temps bien trop rempli ce qui fragilise grandement ce pourquoi elles font ce métier : le temps passé avec le patient. C’est de ce postulat que nous est venue l’idée de la PharmaBox.  

Il s’agit d’une armoire à médicament automatisée qui se situe dans la chambre du patient et qui, à sa demande et après une validation d’une infirmière, délivre un médicament. Ces demandes et validations s’effectuent depuis une interface web. Cela permet ainsi à l’infirmière de gagner du temps en évitant certains déplacements. Ce gain lui permet de passer plus de temps avec ses patients ce qui améliore les conditions de travail des infirmières et de vie des patients. 

Réalisation 

1) Matériel 

La boîte : 

• 6 planches de bois de 450x300x3,5 millimètres
• Deux “entonnoirs” imprimé en 3D
• Deux “tourniquets” imprimé en 3D
• Du velcro adhésif

 

Electronique : 

• Trois leds (Une bleue, une verte, une rouge)
• Une breadboard
• Une carte esp32 (WROOM 32) 
• Deux Moteur pas-à-pas + driver STP01
• Deux batteries 9v pour les moteurs
• Un buzzer SV4
• Des câbles

 

Autres : 

• Un ordinateur
• Découpeuse laser
• Imprimante 3D
• Des vis

 

2) Boîte

 

Nous avons choisi de concevoir une boîte pour mettre en place notre système. Cette boîte est composée de deux compartiments distincts. Le premier, au-dessus n’est accessible que par un(e) infirmier(e). Ce compartiment sert à recevoir l’électronique ainsi que les médicaments.

Figure 1: Partie supérieure de la pharmabox

 

Le second compartiment se trouve en dessous du premier et est composé d’un tiroir coulissant dans l’armature du compartiment. Ce compartiment n’est pas scellé et le tiroir permet de recevoir les médicaments demandés.

Figure 2 : Partie inférieur de la pharmabox, intérieur du tiroir

 

Pour l’armature de la boîte, nous avons sélectionné des designs sur le site boxes.py ( https://www.festi.info/boxes.py/ ) qui permet de générer des fichiers au format SVG afin de pouvoir par la suite découper les différentes faces des deux compartiments avec une découpeuse laser. 

Pour que la découpeuse laser fonctionne correctement et découpe les différentes parties de la boîte, il faut opérer un peu sur les fichiers SVG en question. En effet, il faut mettre tous les contours de chaque élément à découper à une épaisseur de 0.05 mm et le mettre en rouge (canal rouge à 100% et 0% en bleu et vert). On peut voir sur la partie supérieure de la boite 3 LEDs qui informent le patient sur l’état de livraison de sa commande (vert : livrée, rouge : refusée, bleu : en attente). 

 

Le compartiment supérieur possède un couvercle articulé permettant de recharger les médicaments dans les entonnoirs.

Afin d’assurer la distribution des médicaments entre la partie supérieure et le tiroir de la partie inférieure, nous avons choisi de concevoir une pièce que nous appelons l’entonnoir.

Nous avons d’abord réalisé un modèle 3D de la pièce que nous avons retravaillé plusieurs fois afin d’obtenir une pièce qui nous convenait. Enfin, nous avons utilisé une imprimante 3D ultimaker 2 pour imprimer l’entonnoir.

Figure 3 : L’entonnoir

 

Cette pièce à pour but de recevoir des médicaments comme un réservoir. La forme de cette pièce vise à imiter celle d’un entonnoir “classique” afin que les médicaments s’empilent seuls et puissent être distribués de manière granulaire.

Afin d’assurer la granularité, nous avons imaginé une seconde pièce imprimée en 3D que nous appelons tourniquet.

Figure 4 : Le tourniquet

 

A l’aide de cette pièce, qui est reliée à l’arbre d’un moteur pas à pas, nous souhaitons délivrer un seul et unique médicament. Pour cela, nous faisons une rotation de 90° pour qu’un seul médicament puisse être délivré. Si nous voulons distribuer plus d’un médicament, il suffit d’opérer plusieurs rotations à la suite.

Pour assembler toutes ces parties, nous avons d’abord assemblé les deux boîtes séparément, enfin nous avons utilisé du velcro adhésif pour que les deux boîtes restent bien ensemble.

Figure 5 : Les deux compartiments assemblés

 

Pour fixer les entonnoirs et les moteurs, nous avons utilisé quatres morceaux de bois pour entourer les entonnoirs, ils ont été fixés par des vis dans la partie inférieure de la boîte afin de pouvoir fixer le moteur à ces morceaux de bois en ajoutant d’autres vis dans les trous prévus à cet effet dans les moteurs.

Figure 6 : L’entonnoir fixé

 

Pour que l’arbre du moteur puisse s’insérer dans l’entonnoir et ainsi créer la rotation du tourniquet, nous avions préalablement percé l’entonnoir, puis nous avons ensuite collé le tourniquet à l’arbre du moteur avec un pistolet à colle.

Figure 7 : Le tourniquet fixé à l’arbre moteur dans l’entonnoir

 

Enfin, pour la partie électronique dans la boîte, nous avions prévu beaucoup d’espace car nous n’étions pas sûrs de la place que cela nécessiterait, ainsi que le nombre d’entonnoirs que nous voulions mettre en place dans la pharmabox. Nous avons donc dû percer la face avant de la partie supérieure pour que l’on puisse voir les leds (comme sur la figure 2). Le reste de la partie électronique est disposé dans l’espace prévu à cet effet dans la boîte.

Figure 8 : Intérieur de la partie supérieure de la pharmabox avec l’électronique installée.

 

3) Code

 

Le code permettant la gestion de la PharmaBox a été développé avec PlatformIO, un écosystème open source dédié au développement IoT.

 

Dans notre cas, le code source se trouve ICI. Il se compose de plusieurs parties, parmi lesquelles les parties essentielles sont le dossier ‘data’, contenant notre page web et tous les éléments nécessaires à son bon fonctionnement, puis le dossier ‘src’, qui contient le code en C++ permettant les interactions de la carte ESP32 avec les différents éléments électroniques. Enfin, le fichier ‘platformio.ini’ contient les éléments de configuration de la carte électronique ainsi que les bibliothèques nécessaires.

 

4) Électronique 

 

 ESP32 (NodeMCU-32S)

Figure 9 : ESP 32

Notre système utilise 3 LEDs, un buzzer, deux moteurs pas à pas et le protocole de communication Wifi. C’est pour ce dernier aspect que nous avons fait le choix d’un microcontrôleur ESP32. 

 

Un des moteurs pas à pas est contrôlé par les broches (IN1)21, (IN2)19, (IN3)18 et (IN4)5, tandis que le deuxième moteur est commandé par les broches (IN1)26, (IN2)27, (IN3)14 et (IN4)12. Les LEDs bleue, verte et rouge sont respectivement contrôlées par les broches 22, 4 et 2. Le buzzer, quant à lui, est géré par la broche 15.

 

Pour l’hébergement de notre plateforme web et de ses images, nous avons opté pour des librairies spécialisées.

ESPsyncWebServer assure un serveur web asynchrone pour la carte, facilitant la gestion des requêtes web entrantes. Par ailleurs, SPIFFS a été utilisé pour stocker les données, incluant notre page web et nos images, en exploitant la mémoire flash disponible sur la carte.

 

LED 8mm

Figure 10 : LED

 

Les LEDs sont utilisées pour informer le patient de l’état de sa demande et de la livraison de la façon suivante : 

 

• Bleu =  Demande en attente de réponse
• Rouge = demande refusée
• Vert = produit délivré

Caractéristiques : 

• Alimentation: 5 Vcc
• Diamètre: 8 mm

 

Buzzer SV4

Figure 11 : Buzzer

 

Le buzzer est utilisé afin d’informer le patient de l’état de sa demande et livraison. En effet, 1 BIP prolongé (3s) signale la livraison du médicament et 3 BIPs rapides et successifs signalent un refus de la demande. 

 

Caractéristiques : 

• Tension: 5 Vcc​
• Fréquence: 2,5 kHz​
• Intensité: 25 mA
• Niveau sonore: 95 dB sous 12 Vcc à 30 cm
• Diamètre: 23 mm
• Hauteur: 18 mm

 

Moteur pas-à-pas + driver STP01

Figure 12 : Moteur pas-à-pas + driver

Le couple moteur pas-à-pas et driver est utilisé afin de créer la rotation du tourniquet. Il a été calibré pour délivrer la quantité demandée de médicament. En effet, le,moteur pas-à-pas permet d’imposer une rotation précise d’un angle θ. Nous avons imposé une rotation θ adaptée à la distribution d’une pilule. Il suffit de multiplier θ par le nombre de pilule demandée pour obtenir la distribution voulue. 

 

La  librairie utilisée pour contrôler les moteurs pas à pas est Stepper.

 

Caractéristiques : 

• Alimentation : 5 Vcc
• Résistance: 50 Ω
• Intensité: 25 mA
• Réduction: 1/64
• Couple: 300 gf.cm

 

Schéma des branchements

Figure 13 : Schéma de l’installation

5) Interface Web

 

Cette interface est une « Single-page application » ou SPA. Cela signifie que toutes les fonctionnalités sont sur la même page, ce qui permet d’être fluide pour l’utilisateur.

 

Fonctionnalités

Cette application a de multiples fonctionnalités:

– Elle permet au patient de commander en autonomie des médicaments qui ne requièrent pas de prescription.

– Elle permet au personnel infirmier de valider et refuser les commandes de tout les patients.

– Elle permet au personnel infirmier de regarder l’historique de demandes de chaque patient, et leur statut.

– Elle permet au patient d’avoir un traitement plus rapide et indépendant.

Fonctions principales dans le code

Pour pouvoir rester avec l’architecture d’un SPA, chaque interface est présente dans l’écran, mais une seule est visible à l’utilisateur. Pour changer ce qui est visible pour l’utilisateur, nous utilisons les fonctions show<Nom d’Interface>.

Selon le type d’utilisateur chaque interface est différente donc un infirmier peut voir les options qu’un patient peut ne pas voir. Quand tous les utilisateurs peuvent recevoir la même information, on utilise la même fonction pour les deux, donc nous évitons de répéter le code, par exemple la fonction pour montrer l’historique des patients.

 

Tout est dans un seul fichier html, la structure, le style et la fonctionnalité. Seulement les images sont en dehors du fichier. Nous n’avons pas utilisé des frameworks ou libraires. Nous avons créé chaque partie dans le code, chaque fonctionnalité et chaque style avec l’aide d’intelligence artificielle et connaissances déjà acquises. 

 

Démonstration d’utilisation de l’interface web

 

Dans un premier temps, l’utilisateur, qu’il s’agisse d’un patient ou du personnel infirmier, doit se connecter à la plateforme. Pour cette première version les comptes ont été créés en dur dans le code. 

Figure 14 : Page d’identification de l’application

En tant que patient, vous pouvez demander n’importe quelle quantité de médicaments, pour chaque médicament depuis l’onglet  « Accueil ».

Figure 15 : Sélection de médicaments

Une fois que vous avez sélectionné la quantité de médicaments que vous souhaitez commander, vous devez appuyer sur le bouton « commander ». Un message apparaît indiquant les médicaments demandés. Lorsqu’un médicament est commandé, une nouvelle commande est générée, et celle-ci est visible depuis l’onglet « mes demandes ».

Figure 16 : Visualisation de mes demandes en tant que patient 

En tant qu’infirmier, vous pouvez valider ou refuser la commande en cours du client depuis l’onglet « Mes demandes ».

Figure 18 : Visualisation d’une demande d’un patient 

Une fois cette décision prise, la commande du patient est mise à jour. Toutes les commandes de chaque patient sont visibles depuis l’onglet « Mes patients”, en cliquant sur le patient concerné. 

Figure 19 : Historique des demandes d’un patients

6) Protocole de communication

 

Les différents échanges d’informations entre les smartphones utilisant l’interface WEB et la PharmaBox se font grâce à la technologie Wifi, directement intégrée à l’ESP32. Cela présente l’inconvénient de devoir disposer d’une connexion Wifi partout au sein de l’hôpital ou d’une connexion 4G venant du même opérateur que celui qui fournit la connexion Wifi. Nous considérons dans ce projet que tous les utilisateurs sont connectés au Wifi de l’hôpital.

Cet échange est rendu possible grâce à la librairie Wifi qui a permis à notre ESP32 de se connecter à un réseau wifi et d’obtenir ainsi une adresse IP pour notre carte.

 

Résultats 

Nous avons bien réussi à intégrer ensemble les différentes parties de notre solution. En effet nous possédons une vidéo illustrant l’utilisation typique de notre pharmabox. Cependant au moment de la phase de test nous nous sommes rendu compte du potentiel problème lié au design de notre solution. 

 

Par exemple, les tourniquets ne peuvent pas épouser parfaitement la forme de l’arbre du moteur, nous avons relié les entonnoirs aux moteurs grâce à un pistolet à colle. Le problème de cette solution est qu’elle crée pour le moteur une résistance additionnelle qui a rendu le calibrage des moteurs plus compliqué et la solution moins résiliente.

 

Nous avons aussi fait face à un autre souci, celui des batteries, ces dernières se déchargeant de manière très rapide (en seulement une ou deux commandes moteur) nous n’avons pas pu démontrer notre solution en classe. 

 

Hormis ces problèmes, nous n’avons pas rencontré d’autres problèmes sur les autres parties de la solution (site web et affichage des LED). 

 

Perspectives 

 

De nombreuses fonctionnalités nous sont venues à l’idée durant tout le déroulement du projet. Celles que nous avons choisies de réaliser effectivement dans le temps imparti constituent le résultat de celui-ci. Néanmoins, la PharmaBox peut encore être améliorée, voici quelques pistes : 

 

• Ajout d’une base de données dynamique

Dans l’état actuel du prototype, les différentes variables, patient ou infirmière par exemple, sont créées en local. La création d’une base de données serait la meilleure solution pour ajouter/supprimer/modifier ces variables. L’idéal serait même d’accorder cette base de données au système d’information de l’hôpital.  

 

• La modification de demande 

L’infirmière pourrait modifier une demande reçue, par exemple, le type ou le nombre de médicaments mais aussi la posologie. Elle pourrait également ajouter un commentaire à sa réponse.  

 

• La suggestion de médicaments par l’infirmière 

L’infirmière pourrait suggérer à distance depuis l’interface web  la prise d’un médicament à un patient qui pourrait accepter ou refuser cette suggestion. 

 

• La suggestion automatique IA d’un médicament 

Le patient rentrerait depuis l’interface web un niveau de douleur ainsi qu’une description de celle-ci. L’interface web passerait par une IA pour lui suggérer un médicament. 

 

• La présence d’un tutoriel d’utilisation 

Pour rendre l’utilisation du dispositif plus simple pour le patient, il serait possible d’ajouter un tutoriel qui expliquerait les différentes fonctionnalités de la PharmaBox. 

 

• Ajout d’entonnoirs supplémentaires 

Dans l’état actuel du prototype de la PharmaBox, seulement 2 entonnoirs sont présents pour stocker des médicaments. La présence de plus de 2 entonnoirs permettraient d’augmenter le choix de médicaments possible. Il faudrait ainsi adapter la liste de médicaments dans l’interface web.

 

• Ouverture à distance de la partie supérieure de la boîte

Dans l’état actuel du prototype de la PharmaBox, l’ouverture de la partie supérieure de la boîte, utile au renouvellement de stock, n’est pas sécurisée, or il ne faut pas que cette partie puisse être accessible au patient. Il serait possible de déverrouiller la partie supérieure grâce à un cadenas électronique que l’infirmière peut déclencher à distance depuis l’interface web. 

 

• Adaptation médicaments / clients 

Le patient aurait une liste de médicaments auxquels il aurait le droit, certains d’entre eux seront présents dans la pharmaBox. L’interface web doit être adaptée, c’est-à-dire proposer seulement ces médicaments.

 

• Ajout de notifications 

 

Dans l’état actuel du dispositif, le seul moyen pour l’infirmière de recevoir des informations est de se connecter à l’interface web. Le patient est quant à lui informé de l’état de ces demandes par des LEDs et un buzzer. On pourrait ajouter des notifications pour chaque échange d’informations, autant pour les fonctionnalités déjà présentes que pour les fonctionnalités énoncées dans cette section qui pourraient bénéficier de notifications. 

 

Vidéo de fonctionnement du système :

Annexe :

Sources :

Figure 9

Figure 10

Figure 11

Figure 12

Fichiers complémentaires :

Fichiers nécessaires au montage de la pharmabox.

 

LoRa-E5

Envoyé par clanglai le 6 Déc 2023 dans Trucs & astuces | 0 commentaire

La carte LoRa-E5 pour communiquer en LoRaWAN

Il existe pleins de dépôts GitHub qui concerne l’utilisation de la carte LoRa-E5 de Grove [1].

La LoRa-E5 doit être utilisée conjointement avec une carte de développement ESP32 ou arduino. Elle permet de communiquer en LoRa-MAC ou en LoRaWAN [2]. LoRa-MAC permet de communiquer en peer to peer entre 2 noeuds LoRa-MAC, seule la modulation LoRa est mise en oeuvre. LoRaWAN est le protocole réseau qui permet de communiquer avec des opérateurs IoT telles que The Things Network [3].

Pour utiliser la carte LoRa-E5 avec un arduino Leonardo en LoRaWAN, consultez le dépôt GitHub de Sylvain Montagny de l’Université Savoie-MontBlanc [4]. On trouve également une page hacker.io permettant de faire du peer to peer [7].

Les commandes dites AT permettent de contrôler le modem de la LoRa-E5 via la connexion UART de la carte de développement (arduino par exemple) [5]. La liste des commandes AT permettant de commander la carte LoRa-E5 est disponible ici [6].

Références

DeepBlue Tracker – Synthèse de l’enquête terrain et personas

Envoyé par c23leric le 28 Oct 2023 dans TAF COUAD, Projets | 0 commentaire

Synthèse de l’enquête terrain et personas – DeepBlue Tracker

par     Antoine DAGORN        Salomón OJEDA      Clément LERICHE     Théo BARTHÉLEMY     Daniel TAPIA

V2 – 12  novembre  2023

Mise en contexte du projet

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.

 

Introduction

Après avoir fait un état de l’art de notre sujet, nous avons plongé dans le monde concret du terrain. Guidés par la sagacité de Peter Drucker, qui souligne que « il n’y a rien d’aussi inutile que de faire efficacement ce qui ne devrait pas être fait du tout », notre équipe s’est impliquée dans une enquête sur le terrain visant à cerner les besoins réels des parties prenantes de notre problématique. La première partie de ce rapport synthétise notre exploration en mettant en lumière nos hypothèses initiales sur la sécurité en mer et les besoins potentiels des adeptes d’activités sportives concernées. Elle identifie également l’ensemble des parties prenantes par le biais d’une cartographie des acteurs, et résume l’enquête terrain que nous avons mené. Dans la seconde partie, nous avons élaboré et détaillé des personas en utilisant les informations recueillies au cours de notre enquête.

 

PARTIE 1 : ENQUÊTE TERRAIN

Pour entamer cette première partie, nous avons préparé notre enquête sur le terrain en identifiant plusieurs hypothèses que nous avons cherché à valider ou infirmer.

Hypothèses

Hypothèse 1 : Les courants marins sont une cause majeure d’incidents dans la pratique de la chasse sous-marine et de l’apnée.

Cette hypothèse repose sur l’idée que les courants marins sont un facteur prépondérant dans la survenue d’incidents lors de la pratique de la chasse sous-marine et de l’apnée. Les courants marins peuvent avoir un impact significatif sur la sécurité des plongeurs pour plusieurs raisons. Tout d’abord, un déplacement involontaire et parfois difficile à identifier peut-être causé par des courants marins. Ceux-ci peuvent déplacer les plongeurs loin de leur point de départ prévu, les désorientant et les éloignant de leur zone de sécurité. Cela peut entraîner une situation potentiellement dangereuse si le plongeur n’a pas anticipé ces mouvements. Ils sont en effet responsables d’une fatigue accrue : nager contre des courants forts peut exiger des efforts physiques considérables, ce qui peut fatiguer rapidement un plongeur. Par ailleurs, ils peuvent nécessiter au chasseur ou à l’apnéiste de rester en mer plus longtemps qu’anticipé, le fatiguant là aussi. La fatigue peut alors entraîner une diminution de la vigilance et de la capacité à réagir en cas de problème, voire un essoufflement ou une noyade.

 

Hypothèse 2 : La difficulté et la lenteur à localiser un nageur en difficulté augmentent la gravité des incidents.

Cette hypothèse suggère que le temps nécessaire pour localiser/repérer un plongeur en difficulté à un impact significatif sur la gravité des incidents lors de la pratique de la chasse sous-marine et de l’apnée. Plusieurs éléments entrent en jeu pour expliquer cette hypothèse. Tout d’abord, la détérioration rapide de l’état de santé dans un milieu hostile peut être évoquée. En effet, lorsqu’un plongeur rencontre des problèmes sous l’eau et n’est pas rapidement identifié, sa condition physique peut se détériorer bien plus rapidement que sur la terre ferme. En cause, le froid, la houle, le stress…, peuvent créer des situations très dangereuses rapidement. Cela peut inclure des problèmes de respiration, des évanouissements, ou des situations de panique, ce qui peut aggraver la situation. Ainsi, si un plongeur en difficulté n’est pas repéré rapidement, il peut courir un risque plus élevé de noyade qui peut être dû à la perte de conscience, à l’épuisement ou à la perte de flottabilité.

 

Hypothèse 3 : Le manque de communication et de suivi des pratiquants provoque une latence dans l’intervention des secours.

Cette hypothèse suggère que les problèmes de communication entre les pratiquants et les services de secours peuvent entraîner un retard dans l’arrivée de l’aide en cas d’incident lors de la pratique de la chasse sous-marine et de l’apnée. Plusieurs éléments sont à considérer pour comprendre cette hypothèse. La communication étant limitée sous l’eau, les plongeurs sous-marins et les apnéistes sont souvent confrontés à des limitations en raison de l’absence de dispositifs de communication étanches et efficaces. Cela peut compliquer la transmission d’informations cruciales aux équipes de secours en cas d’incident. En raison de ces limitations, les plongeurs en difficulté ne peuvent pas appeler à l’aide ou peuvent ne pas être en mesure de le faire rapidement. Cela peut entraîner un retard dans l’intervention des secours. Par ailleurs, comme évoqué dans l’hypothèse précédente, les services de secours peuvent rencontrer des difficultés pour localiser les plongeurs en détresse en temps opportun en raison du manque de coordonnées précises ou de la difficulté à comprendre la gravité de la situation liée à cette absence de communication.

 

Hypothèse 4 : Les proches des chasseurs sous-marins et des apnéistes partant en solitaire prennent conscience trop tard des incidents.

Cette hypothèse repose sur l’idée que les personnes proches des chasseurs sous-marins et des apnéistes qui partent en solitaire ne sont pas suffisamment informées pour reconnaître rapidement un incident en cours. Non seulement il pourrait manquer d’une compréhension des dangers. Les proches des plongeurs en solitaire peuvent ne pas être pleinement conscients des risques potentiels associés à ces activités, notamment des situations d’urgence sous l’eau.

De plus, l’absence de signaux d’alerte dans le cas où les proches des ne sont pas suffisamment informés peuvent créer des difficultés pour ceux-ci à reconnaître les signaux d’alarme potentiels qu’un chasseur sous-marin pourrait, par exemple, essayer de communiquer visuellement depuis l’eau vers la plage et ses proches.

Par ailleurs, dans le cadre d’une pratique en solitaire, les proches seraient susceptibles d’appeler les secours qu’après s’être rendu compte que le chasseur ou l’apnéiste n’est pas revenu de sa séance. Il est alors probablement trop tard pour une intervention efficace des secours, car l’incident est possiblement survenu plusieurs heures auparavant, le pratiquant est alors en situation critique et le retrouver est problématique, car le périmètre de recherche s’est considérablement élargi.

 

Hypothèse 5 : Les proches des sportifs en mer ont probablement besoin d’un suivi en temps réel pour assurer leur tranquillité d’esprit et renforcer la sécurité perçue.

Cette hypothèse découle de la nature souvent isolée et potentiellement risquée des activités nautiques en solitaire. Les proches des sportifs peuvent ressentir une inquiétude naturelle liée à l’éloignement en mer, amplifiée par l’absence de visibilité directe sur l’évolution de la situation. Ainsi, un suivi en temps réel pourrait répondre à leur besoin de rester informés et assurerait un sentiment de sécurité accru en leur permettant de suivre l’activité sportive de leur proche de manière instantanée et fiable, contribuant ainsi à apaiser leurs préoccupations.

 

CARTOGRAPHIE DES ACTEURS

• Chasseurs sous-marins et apnéistes 

Les chasseurs sous-marins et les apnéistes forment une communauté diversifiée, allant des débutants aux professionnels, pratiquant en solitaire ou au sein de clubs nautiques. Les clubs organisent des sorties en groupe, depuis la côte ou en bateau, pour une meilleure coordination et sécurité collective. Les chasseurs sous-marins utilisent un équipement spécialisé, tandis que les apnéistes se concentrent sur la maîtrise de la respiration. Leurs motivations varient, de la recherche de nourriture à l’exploration ou au plaisir de l’immersion. Cette diversité impacte la gestion des risques, les compétences, la compréhension des dangers et la réactivité en cas d’incident. La sécurité de cette communauté est cruciale pour l’ensemble de ces activités.

• Services de secours

Les services de secours jouent un rôle essentiel dans la sécurité des chasseurs sous-marins et apnéistes en intervenant en cas d’incident pour le sauvetage et les soins médicaux. Certains sont spécialisés dans le sauvetage en mer, tels que la SNSM et le CROSS, avec des compétences spécifiques pour les opérations en eau profonde. D’autres services de secours plus généraux, comme les pompiers et les garde-côtes, interviennent également. La rapidité et l’efficacité de leur réponse dépendent de la coordination, de la communication avec les plongeurs en détresse et de la connaissance des zones de plongée. Leur réactivité, coordination et compétence sont cruciales pour assurer la sécurité des chasseurs sous-marins et apnéistes en cas d’incident, notamment en situations d’urgence en mer.

• Proches des chasseurs sous-marins et apnéistes 

Les proches des chasseurs sous-marins et apnéistes jouent un rôle essentiel dans leur sécurité, surtout lorsqu’ils pratiquent en solitaire. Leur connaissance des activités et des dangers associés les rend plus attentifs aux signaux d’alarme. En outre, les pratiquants peuvent informer leurs proches de leurs sorties planifiées, fournissant des détails essentiels. Ces proches peuvent être formés pour reconnaître les signes d’incident et alerter rapidement les services de secours en cas de besoin. Leur implication peut accélérer la réponse aux situations d’urgence en mer. Il est donc crucial que les proches soient informés, sensibilisés et prêts à réagir, contribuant ainsi à renforcer la sécurité des chasseurs sous-marins et apnéistes.

 

Déroulement de la recherche sur le terrain

Au cœur de notre démarche de recherche sur le terrain, les interviews ont été essentielles pour approfondir notre compréhension des enjeux actuels et des défis de sécurité inhérents aux sports nautiques.

Entretien 1 

Prise de contact

Nos recherches sur internet nous ont conduits au site web de la Fédération Française de Pêche Sportive en Apnée, abrégée FFPSA. Suite à cette découverte, nous avons contacté cette fédération via un formulaire en ligne. Rapidement, nous avons reçu une réponse du président de la fédération par courriel, M. Jean. Après quelques échanges téléphoniques, nous avons convenu d’un entretien en visioconférence. 

Déroulé de l’entretien

En plus d’être le président de la FFPSA, M. Jean est un adepte de la chasse sous-marine en apnée, il la pratique régulièrement avec les membres de son club local.

M. Jean souligne que la FFPSA assume principalement un rôle administratif. Devenue délégataire seulement depuis 2022, la fédération est désormais habilitée à organiser des compétitions sportives. À ce jour, la fédération ne représente que 5% des 100 000 pratiquants en France.

En situation de détresse, M. Jean explique que c’est essentiellement la SNSM qui intervient, représentant 80% des opérations de sauvetage. Cependant, ce sont les CROSS qui font le lien entre l’alerte et les secours (SNSM, pompiers, etc.) via la VHF, ils gèrent l’organisation des secours.

Un chiffre alarmant partagé lors de notre discussion est celui d’un décès pour 1 000 pratiquants. L’État considère cette activité comme dangereuse. Bien qu’une assurance responsabilité civile soit le seul document formellement requis pour pêcher, un certificat médical est nécessaire pour adhérer à la fédération.

Concernant l’accidentologie, bien que le taux d’accidents soit élevé, il n’est pas chiffré avec précision. La SNSM fournit des statistiques, mais elles englobent diverses situations sans distinguer spécifiquement les activités à l’origine de la détresse.

Le président de la FFPSA indique qu’en chasse sous-marine, la cause principale d’accident est la syncope : souvent, le plongeur surestime ses limites, s’aventure trop profondément et perd connaissance en remontant. M. Jean nous indique que des équipements de sécurité sont disponibles pour les plongeurs. Parmi eux, un gilet relié à une montre qui se gonfle automatiquement permet de remonter le plongeur à la surface sans effort en cas de problème.  Légalement, les plongeurs doivent utiliser une bouée en surface pour signaler leur position de plongée. Cette bouée, généralement de couleur vive comme l’orange, arbore un pavillon à la croix de Saint-André. Toutefois, son efficacité en cas de houle est remise en question par le président. Cela augmente les risques pour les plongeurs vis-à-vis des autres bateaux (collisions, etc.). Il prend l’exemple d’une situation qui arrive régulièrement : lorsqu’il y a plusieurs plongeurs largués par un bateau : Récupérer plusieurs plongeurs peut être complexe, car c’est compliqué de se faire voir dans l’eau, un bras étant très petit.

De plus, selon lui, la situation à éviter à tout prix est la perte d’un plongeur en mer sans possibilité de retrouver son corps. La récupération du corps est essentielle pour permettre à la famille de faire son deuil, en plus de résoudre d’éventuels problèmes avec les assurances.

M. Jean nous résume les problématiques en mer en quelques points majeurs :

• La visibilité du plongeur (bouée, pavillon), en précisant que la peinture fluorescente est très bien visible avec une vision nocturne
• Utilisation actuelle de combinaison sombre/camo peu visible dans l’eau
• Manque de moyen de communication efficace avec les autres

Selon lui, l’équipement de sécurité optimal doit être robuste, visible de loin, capable de signaler la présence ou la détresse aux secours, tout en restant compact.

De plus, M. Jean insiste que les pratiquants de sa fédération sont des compétiteurs très bien équipe, ce qui n’est pas le cas de la majorité des pratiquants de son sport.

Enfin, il mentionne que la première mesure de prévention consiste à éviter de partir seul, en particulier en rejoignant un club (pour apprendre les bases et vérifier son matériel).

L’entretien se conclut par un M. Jean qui nous donne le contact de son vice-président, basé à Brest, qui manifeste un vif intérêt pour la sécurité en mer liée à cette pratique sportive.

Enseignements clefs

Cet entretien souligne les problèmes de sécurité sont bien réels et nécessite davantage de solutions. Il a été mis en évidence les problèmes de visibilité des plongeurs lorsqu’ils sont en mer. Il faut qu’ils soient visibles des autres bateaux et des autres plongeurs. De plus, si le plongeur est en solitaire, il faut trouver un moyen pour détecter qu’un nageur à un problème de santé et ainsi prévenir les secours. Enfin, connaitre la position du plongeur à chaque instant permettrait de le retrouver en cas de problème.

Cet entretien valide la quasi-totalité de nos hypothèses, à l’exception de la dernière qui n’est pas explicitée.

Entretien 2

Prise de contact 

À la suite de notre entretien avec le président de la FFPSA, celui-ci nous a fourni une liste de contacts. Dans cette liste se trouvait un certain M. Océan, vice-président de la fédération et résidant à Plouzané.

Déroulé de l’entretien

Le vice-président de l’association FFPSA, âgé de 54 ans, incarne l’expérience dans le monde de la pêche en apnée. Plongeur chevronné depuis l’âge de 15 ans, sa navigation au sein de cette pratique illustre un parcours riche en expériences, conférant une perspective informée et nuancée aux défis et enjeux abordés au sein de l’association

Outre sa passion pour la pêche, il a également servi en tant qu’officier des ressources humaines dans la marine. Avec une pléthore de titres à son actif, il a également endossé le rôle de formateur au niveau national et est un membre éminent de la conférence « Mer et Liberté », se consacrant à divers aspects de la pêche en mer. Cependant, parmi les nombreuses casquettes qu’il porte, le sauvetage en mer tient une place particulière dans son cœur. Il a souligné à quel point c’était crucial, en rappelant les tristes incidents de cette année, notamment les décès de deux individus, âgés respectivement de 22 et 54 ans. Ces incidents mettent en lumière la nécessité impérative de la sécurité et de la préparation en mer, thèmes que nous avons explorés en profondeur lors de notre discussion.

La pêche sous-marine comportant des dangers et des problématiques spécifiques que le vice-président de la FFPSA a soulevés au cours de l’interview. En premier lieu, les conditions météorologiques peuvent varier drastiquement, rendant le milieu marin imprévisible et parfois hostile. La faune et la flore, bien qu’enrichissantes, présentent également des risques, comme les piqûres ou les morsures de certaines espèces marines. Les aspects physiologiques, tels que l’hyperventilation et la syncope, sont des phénomènes courants et dangereux pour les plongeurs pas suffisamment entraînés.

M. Océan explique que l’imprudence et la méconnaissance accentuent ces dangers et qu’un manque de formation et de connaissance de la réglementation en vigueur peut conduire à des situations risquées. De plus, pour M. Océan, l’absence d’équipements de sécurité adéquats est une cause majeure de nombreux incidents. Le vice-président a aussi partagé des exemples concrets d’incidents et d’accidents récents, illustrant des cas de noyades et de syncopes. Les difficultés rencontrées lors de la localisation et du sauvetage des plongeurs en détresse soulignent l’importance d’une préparation adéquate et d’une meilleure compréhension des dangers inhérents à la pêche sous-marine. Cette analyse précise vise à établir un cadre clair pour des mesures de sécurité renforcées dans cette activité.

Face aux défis et dangers identifiés en pêche sous-marine, le vice-président de la FFPSA évoque des solutions et innovations cruciales pour améliorer la sécurité. D’abord, l’adoption d’équipements de sécurité est primordiale. Il rappelle l’existence d’un gilet de sauvetage automatique. Les bouées, montres et balises de localisation, de leur côté, peuvent grandement faciliter la localisation rapide des plongeurs en cas de besoin. D’autres dispositifs d’alerte et de communication peuvent également contribuer à renforcer la sécurité en permettant une réaction rapide en cas d’incident, comme la VHF mais celle-ci n’est disponible que sur les bateaux et est trop volumineuse pour un plongeur.

Ensuite, la formation et la sensibilisation sont des axes majeurs d’amélioration selon lui. Une formation adéquate sur les règles de sécurité, les bonnes pratiques et les réponses en cas d’urgence sont indispensables pour réduire les risques. Par ailleurs, une campagne de sensibilisation efficace peut aider à instiller une conscience accrue des dangers inhérents à la pêche sous-marine et de l’importance de la préparation.

Enfin, le vice-président souligne l’importance des projets et de la recherche en cours pour développer des solutions novatrices. Des projets visant à améliorer la localisation et le sauvetage des plongeurs sont en cours, en collaboration avec l’Irenav et d’autres institutions. Ces initiatives, en synergie avec les équipements de sécurité et les programmes de formation, représentent une approche globale pour rehausser les standards de sécurité dans la pêche sous-marine, et ainsi, minimiser les risques et maximiser la protection des pratiquants.

Enseignements clefs

L’entretien avec M. Océan, vice-président de la FFPSA, a souligné sa grande expérience dans la pêche en apnée et le sauvetage en mer ; les dangers inhérents à cette activité, exacerbés par l’imprudence et le manque de formation. Les solutions proposées incluent l’adoption d’équipements de sécurité, des formations approfondies sur les règles de sécurité et la sensibilisation aux risques. L’importance des innovations et des projets de recherche collaboratifs, visant à améliorer la localisation et le sauvetage des plongeurs, a été mise en avant comme un élément clé pour améliorer la sécurité globale dans le domaine de la pêche sous-marine.

Entretien 3

Prise de contact 

Le sauveteur de la SNSM que nous avons interviewé est une connexion personnelle, nous l’avons rencontré au sein de l’IMT Atlantique et ayant appris son engagement envers la SNSM nous avons voulu en savoir plus sur son expérience et l’avons interviewé.

Déroulé de l’entretien

Le sauveteur interviewé a intégré la Société Nationale de Sauvetage en Mer (SNSM) à l’âge de 17 ans. Initialement engagé comme sauveteur et secouriste, il a par la suite évolué vers le poste de sauveteur embarqué au sein de la SNSM.

Au sein de la SNSM, une distinction est faite entre les sauveteurs des plages municipales et les sauveteurs à l’année rattachés à une station de la SNSM. Les alertes sont principalement gérées par le CROSS qui, en fonction de la nature de l’incident et de la localisation, déclenche les opérations de secours. Les interventions varient de l’assistance en cas de panne mécanique sur un navire à la recherche de personnes disparues en mer.

Le financement de la SNSM repose en grande partie sur le bénévolat, complété par des dons et des fonds générés lors d’événements organisés. Le centre de formation de Rennes se distingue comme un élément central de la formation des sauveteurs, leur fournissant les compétences nécessaires pour exercer leur mission de sauvetage en mer. Ce centre, reconnu comme le plus grand de France, contribue activement à maintenir un haut niveau de professionnalisme et de réactivité parmi les sauveteurs de la SNSM, renforçant ainsi leur capacité à intervenir efficacement en toutes circonstances.

D’après le sauveteur, la localisation précise des victimes en mer est cruciale pour garantir une intervention rapide et efficace. Actuellement, le manque d’informations précises et les fausses alertes représentent des défis majeurs pour les équipes de sauvetage. Ces obstacles peuvent entraver les opérations de secours, voire mobiliser inutilement des ressources. Des outils de localisation et de communication sont utilisés ou en cours de développement, tels que la montre SNSM et les radios VHF, qui visent à améliorer la coordination entre les sauveteurs et à fournir des informations en temps réel sur la situation en mer. L’amélioration de ces dispositifs est essentielle pour optimiser les interventions de sauvetage et assurer la sécurité des individus en mer.

Les catégories de personnes les plus touchées lors d’incidents en mer comprennent les enfants, les personnes âgées, ainsi que les individus surestimant leurs capacités. Certains environnements ou situations spécifiques exacerbent ces risques, comme en témoigne l’exemple des falaises de Théoule, où le saut peut entraîner des traumatismes cervicaux, affectant des individus de tous âges. Post-sauvetage, certaines implications médicales sont à noter, notamment la nécessité de consultations médicales obligatoires. Cette exigence est particulièrement pertinente pour les personnes âgées, qui peuvent présenter des symptômes ou des complications nécessitant une évaluation et une intervention médicale immédiates, tel que l’aqua stress.

Enseignements clefs

L’interview du sauveteur de la SNSM a révélé l’importance de la formation et de la localisation précise des victimes pour une intervention rapide et efficace. L’entretien a également souligné les défis actuels tels que le manque d’informations précises et les fausses alertes, qui peuvent entraver les opérations de secours. L’accent a été mis sur le développement d’outils de localisation et de communication. Les catégories de personnes les plus touchées lors d’incidents en mer ont été identifiées, et des implications médicales post-sauvetage ont été discutées, mettant en exergue la nécessité de consultations médicales pour certaines victimes, notamment les personnes âgées.

Entretien 4

Prise de contact 

Théo fait partie de notre projet, la prise de contact s’est faite en face-à-face.

Déroulé de l’entretien

• Question 1: Théo, peux-tu nous expliquer ce qui t’a poussé à te lancer dans la chasse sous-marine en solitaire?

  Réponse de Théo: Eh bien, en fait, j’ai toujours été attiré par l’océan et la vie marine. Mais la plupart de mes amis ne partagent pas cette passion, alors j’ai décidé de me lancer seul. C’est un peu intimidant, je dois l’admettre.

• Question 2: Tu as mentionné que ta principale préoccupation était la sécurité. Quels sont les aspects qui t’ont inquiété et comment as-tu abordé cette question?Réponse de Théo: Oui, c’est vrai. Je veux dire, plonger seul comporte ses risques, et ma principale préoccupation était de m’assurer que si quelque chose devait arriver, mes proches seraient informés. J’ai donc pensé à un dispositif de sécurité.
• Question 3: Parlons de l’équipement que tu as acheté. Comment as-tu choisi tes équipements, et qu’est-ce qui t’a semblé essentiel pour assurer ta sécurité?Réponse de Théo: J’ai fait beaucoup de recherches en ligne, consulté des forums, et j’ai également demandé des conseils à des experts. J’ai investi dans une combinaison de plongée de qualité, un bon équipement respiratoire, et j’ai également acheté une bouée de signalisation. Mais même avec tout cela, je sentais qu’il manquait quelque chose pour rassurer ma famille.
• Question 4: C’est là que ton projet entre en jeu. Peux-tu nous parler de l’idée de la bouée connectée et comment elle répond à tes préoccupations de sécurité?Réponse de Théo: Exactement. L’idée de la bouée connectée m’est venue en pensant à un dispositif qui pourrait envoyer un signal à mes proches pour leur dire que tout va bien. Quelque chose de simple à utiliser pendant mes plongées.

• Question 5: En conclusion, quelles leçons tirées de ton expérience pourraient être utiles aux autres débutants qui envisagent la chasse sous-marine en solitaire?

  Réponse de Théo: Je dirais que la préparation est la clé. Investir dans un équipement de qualité est essentiel, mais réfléchir à la sécurité et à la tranquillité d’esprit de vos proches l’est tout autant. La bouée connectée pourrait vraiment être une solution pour ceux qui se lancent dans cette aventure en solitaire.

Enseignements clefs

L’entretien avec Théo révèle des enseignements clés pour les débutants en chasse sous-marine solitaire. Sa motivation personnelle, guidée par une passion pour l’océan, est évidente, mais il souligne également des préoccupations de sécurité. Théo a pris des décisions éclairées dans le choix de son équipement, en mettant l’accent sur la qualité. Son besoin de rassurer sa famille a conduit à l’idée innovante d’une bouée connectée, démontrant ainsi l’importance de la préparation et de solutions créatives pour assurer la sécurité et la tranquillité d’esprit des plongeurs solitaires.

 

PARTIE 2 : PERSONAS

Persona n°1 : Théo

Description du personnage :

Théo est un chasseur sous-marin qui, bien que peu expérimenté, est très consciencieux et bien renseigné sur les pratiques de chasse sous-marine. Contrairement à ses confrères plus réguliers, Théo ne fait pas partie d’un club de chasse sous-marine. Il préfère chasse en solitaire quand il en a l’occasion, en veillant toujours à sa propre sécurité et à celle de l’environnement marin qu’il explore.

But et défi :

Le principal objectif de Théo est de passer un bon moment tout en découvrant la beauté des fonds marins. Il chasse pour le plaisir et espère ramener un poisson comme récompense de ses efforts. Cependant, son défi est de réaliser cela en toute sécurité, malgré son manque d’expérience en chasse sous-marine.

Craintes :

Théo a plusieurs craintes qui le hantent chaque fois qu’il part en chasse sous-marine en solitaire. Sa principale crainte est de se noyer ou d’être emporté par le courant, car il sait qu’une mauvaise décision ou un accident peuvent avoir des conséquences graves en mer. Il redoute également de ne pas réussir à revenir à la surface après une plongée, ce qui peut être angoissant.

Comme il est seul, il sait que le moindre danger peut avoir de lourdes conséquences.

Éléments défavorables :

Plusieurs éléments défavorables peuvent compliquer l’expérience de Théo en tant que chasseur sous-marin inexpérimenté. La météo peut être imprévisible en mer, et une mauvaise météo peut rendre la plongée plus dangereuse. Son manque d’expérience peut également le mettre face à des situations inattendues ou difficiles à gérer. 

Le fait de chasser en solitaire est un élément défavorable majeur, les responsables de la FFPSA nous ont clairement indiqué que c’était une pratique accentuant significativement le risque d’accident graves. Néanmoins, comme l’achat d’équipement et la pratique ne nécessitent ni permis, ni formation, c’est un cas de figure commun. Ainsi, Théo n’a pas la sécurité supplémentaire fournie par un groupe ou un club de chasse sous-marine. Cela signifie qu’il doit prendre des décisions cruciales lui-même et compter sur ses connaissances limitées, sans la sécurité qu’un partenaire pourrait lui apporter.

Éléments favorables :

Tout d’abord, il peut arriver à Théo de trouver des partenaires de chasse occasionnels parmi ses connaissances ou par l’intermédiaire de forums de chasse sous-marine.

Des conditions en mer et météorologiques faciles sont également favorables puisqu’elles limitent les risques de syncope, de noyade, de courants… Elles facilitent également la visée et la visibilité pour chasser efficacement.

Problèmes liés à la pratique :

Les problèmes qui occupent l’esprit de Théo sont sa visibilité par les plaisanciers (bateaux, nageurs, pêcheurs…), et son attention vis-à-vis d’évènements inattendus qui pourraient subvenir lors de sa séance de chasse.

Opportunités :

Théo a remarqué l’inquiétude que génère la pratique de son activité chez ses proches. Il aimerait avoir l’opportunité de les rassurer. 

Besoin :

Comme Théo est un chasseur consciencieux, il a avant tout besoin d’assurer sa sécurité et de se rassurer.

 

Persona n°2 : Christian

Description du personnage :

Christian est un chasseur sous-marin expérimenté, fortement attaché à son binôme qu’il considère comme un frère et avec qui il plonge systématiquement. Leur partenariat solide est le résultat de nombreuses sorties sous-marines conjointes, et leur confiance mutuelle est inébranlable. Il chérit la sécurité et le bien-être de son binôme par-dessus tout, ce qui se traduit par une grande responsabilité dans la gestion de leurs expéditions.

But et défi :

Le but principal de Christian est de chasser des poissons, mais il place avant tout la sécurité de son binôme en tête de ses priorités. Il s’efforce de garantir que son compagnon de chasse reste en sécurité à tout moment et ne subisse aucun incident. Pour lui, il n’y a rien de pire que de perdre son binôme dans un accident de plongée.

Opportunités :

Christian étant un chasseur régulier, il souhaiterait également pouvoir rassurer et informer ses proches lors de ses multiples sorties. Ce point a également été relevé par les chasseurs expérimentés que nous avons interrogés.

Craintes :

Les craintes qui animent Christian sont liées aux conditions en mer et concernent la sécurité de son coéquipier. En effet, la sécurité de son binôme est pour lui très importante, Jean-Michel cherche à tout prix à garder en vue son partenaire. Ainsi, perdre de vue son camarade à cause d’une météo dégradée ou d’une mer qui s’agite représente pour lui une crainte importante.

Par ailleurs, Christian est également soucieux de sa propre sécurité. Ainsi, il a peur d’être perdu de vue ou de subir une syncope.

Éléments défavorables :

Malgré son expérience et son souci de sécurité, Christian peut parfois faire preuve d’un excès de confiance. Il peut sous-estimer les risques liés à la chasse sous-marine, ce qui peut le rendre moins vigilant face aux aléas de la nature. Cette confiance excessive peut parfois le conduire à prendre des risques inutiles.

Les aléas de la nature, tels que la météo imprévisible ou les courants marins changeants, sont des éléments défavorables qui peuvent rendre la chasse sous-marine plus difficile. Christian doit être prêt à faire face à ces défis imprévus tout en protégeant la sécurité de son binôme.

Il doit également rester constamment vigilant pour prévenir les syncopes de son binôme. La syncope est un des risques majeurs les plus fréquents en chasse sous-marine, et Christian doit être capable de reconnaître les signes avant-coureurs et de réagir rapidement pour éviter des accidents graves. 

Ces informations ont été tirées d’un croisement entre nos entretiens (où les personnes interviewées nous ont exposé les principaux éléments à risque de la pratique) et des données statistiques issues de la veille documentaire.

Éléments favorables :

A l’inverse, des conditions météorologiques favorables permettant une meilleure visibilité et une meilleure appréhension de son environnement sont des éléments favorables à Christian dans le cadre de sa pratique sportive.

De plus, chasser avec un coéquipier expérimenté permet d’améliorer sa sécurité, car lui aussi sera alerte et apte à déceler de potentiels dangers. 

Problèmes liés à la pratique :

Les aléas de la nature ainsi que la visibilité par les autres plaisanciers sont les deux principaux problèmes que Christian doit garder en tête lors de ses sorties. En effet, il doit constamment pouvoir déceler de potentielles situations à risque pour lui où son binôme, comme des conditions en mer changeant rapidement, visibilité qui se dégrade, une collision avec un bateau… afin de rester en sécurité.

Le cas du danger de collision a par exemple été évoqué dans un de nos entretiens car le chasseur y avait personnellement fait face et qu’il se produit relativement fréquemment.

Besoin :

Le besoin de Christian est centré sur sa sécurité et celle de son partenaire. Il est ainsi à la recherche de dispositifs facilitant un suivi mutuel et donc réduisant les dangers d’une sortie en mer. Il désirerait par ailleurs rassurer ses proches à l’aide d’un moyen de communication.

Persona n°3 : Marine

 

Description du personnage :

Marine est la mère de Théo

But et défi :

Marine, 50 ans, la mère de Théo, cherche à soutenir la passion de son fils pour la plongée en apnée tout en garantissant sa sécurité. Son défi est de concilier son inquiétude maternelle avec le besoin de Théo d’explorer les profondeurs en solitaire.

Craintes :

Marine craint constamment pour la sécurité de Théo lors de ses plongées en apnée, surtout en solitaire. Elle redoute les dangers potentiels et a une peur profonde que son fils puisse être exposé à des situations risquées. Sa principale crainte est de ne pas pouvoir assurer la sécurité de Théo lors de ses aventures sous-marines.

Éléments défavorables :

Le principal élément défavorable est l’incertitude liée à l’état et à la localisation de Théo pendant ses plongées en apnée. L’absence d’informations en temps réel augmente l’anxiété de Marine, ne lui permettant pas de s’assurer que son fils pratique en toute sécurité.

Éléments favorables :

Les compétences et la passion de Théo pour la plongée en apnée sont des éléments favorables. Marine sait que Théo est conscient des risques, prend des précautions et possède une connaissance approfondie des pratiques de sécurité. Ces éléments la rassurent, mais elle cherche toujours des moyens d’améliorer la communication et la sécurité.

Problèmes liés à la pratique :

Le problème majeur est le manque d’informations en temps réel sur l’état et la localisation de Théo pendant ses plongées. Cette lacune crée un défi supplémentaire pour rassurer Marine et maintenir une communication ouverte avec son fils pendant ses expéditions sous-marines.

Besoin :

Le besoin critique de Marine est de disposer d’un moyen fiable de connaître l’état de Théo et sa localisation pendant ses plongées en apnée. Elle souhaite recevoir des mises à jour régulières pour apaiser ses inquiétudes et garantir la sécurité de son fils. La mise en place d’un système de communication en temps réel devient une priorité pour répondre à ce besoin crucial.

Conclusion

En conclusion, cette enquête sur le terrain a été essentielle pour valider nos hypothèses. L’expérience partagée par les personnes interrogées nous a guidés de manière significative en nous fournissant des indications précieuses sur les besoins actuels dans les disciplines sportives qui suscitent notre intérêt. Grâce à cette enquête approfondie, nous sommes désormais assurés de développer une réponse pertinente en adéquation avec les attentes et les réalités du terrain.

Jardin Partagé – Enquête terrain

Envoyé par s23kango le 27 Oct 2023 dans Projets, Blog, TAF COUAD | 0 commentaire

 

Partie 1 – Synthèse de l’enquête terrain

Partie 2 – Persona

Partie 3 – Exemples de guide d’entretien

 

Les auteurs

 

Partie 1 – Synthèse de l’enquête terrain

Les premières idées que nous avions de ce projet étaient centrées autour des espaces verts dans les espaces urbains, ce qui comprenait les parcs et les jardins. Pour autant, nous nous sommes rapidement focalisés sur les jardins communautaires et plus particulièrement les jardins partagés.

Les jardins partagés sont des jardins communautaires qui regroupent différents acteurs : associations, collectivités, structure de quartier et bénévoles. Il s’agissait pour nous de voir comment ce mélange de profils participe à la dynamique des jardins et peut influencer positivement ou négativement leur fonctionnement. L’idée qui nous est venue est la mise en place de capteurs dans le jardin afin de monitorer plus facilement l’ensemble des parcelles et des cultures.

Sur le territoire de Brest Métropole, la demande de mise en place d’un nouveau jardin se fait le plus souvent par un groupe d’habitants auprès de la mairie de quartier. En fonction des espaces disponibles dans le quartier, la mairie de quartier met à disposition un terrain avec l’accord de la mairie de Brest Métropole. Ces demandes passent par la direction des espaces verts de Brest Métropole puisque c’est elle qui centralise et qui s’occupe de tous les espaces publics appartenant à la mairie de Brest Métropole. Des associations, telle que Vert le Jardin, peuvent accompagner la mise en place technique d’un nouveau jardin, mais également la partie administrative avec la composition du dossier de demande auprès de la mairie et le financement. Des animations peuvent également être mises en place avec l’aide d’une association ou d’une maison pour tous afin de faire connaître le jardin et fédérer plus d’habitants dans le quartier.

 

Fig. 1 : Schéma de tous les acteurs autour des jardins partagés

A travers une première recherche documentaire, nous avons listé tous les acteurs liés aux jardins partagés (cf. Fig. 1) qui nous venaient en tête et avons sélectionné les plus pertinents. Nous avons donc contacté les acteurs suivants :

• La mairie de Brest Métropole
• Les mairies de quartier / Les maisons pour tous (MPT)
• Les associations présentes sur le territoire de Brest métropole
• Visite des jardins 
• Rencontre avec des bénévoles

Les questions posées lors des entretiens sont ajustées en fonction des différents acteurs, mais des thèmes principaux peuvent être mis en avant comme son rôle dans le jardin, la mise en place d’un nouveau jardin dans un quartier et ce que cela implique ainsi que la dynamique entre tous les acteurs.

Nous avons établi trois guides différents pour les acteurs principaux, disponibles en fin d’article. Premièrement, nous avons la direction des espaces verts de Brest Métropole. Nous avons rencontré un des principaux responsables qui nous a partagé le fonctionnement de cette entité au sein de Brest Métropole. Les trois thèmes autour desquels nous avions préparé les questions étaient, les espaces verts, les jardins partagés et la législation. Nous avons beaucoup appris sur leur gestion de l’eau. Ils possèdent un récupérateur d’eau de pluie dans l’horticulture qui est une infrastructure qui leur permet de faire pousser les fleurs. Ces fleurs sont ensuite utilisées pour agrémenter les ronds-points et les différents espaces publics de la ville. L’eau récupérée est également acheminée vers les jardins partagés en cas de besoin lors de forte sécheresse en été. L’utilisation de sondes afin de monitorer les massifs présents sur le territoire de la métropole nous a également beaucoup orienté et conforté dans l’idée d’utiliser des capteurs pour les jardins. Cet entretien nous a donc été bénéfique d’un point de vue technique puisqu’il nous a permis de mieux comprendre les enjeux liés à l’eau et au monitoring des espaces verts. Nous avons conclu que dans le cadre de notre projet et avec les moyens qui nous sont mis à disposition, il serait difficile de mettre en place une solution en lien avec la récupération et la gestion de l’eau de pluie. L’installation de telles infrastructures peut demander un financement et des travaux importants. Concernant le monitoring, cette discussion nous a donné un aperçu plus précis des données de capteurs qu’il serait intéressant de collecter.

Le deuxième type d’acteur que nous avons rencontré est les animateurs. Nous avons pu mener un entretien officiel et trois entretiens informels. Un animateur est une personne qui possède ou non des connaissances techniques en jardinage. Elle aide à la mise en place et au maintien des jardins partagés. Grâce à ces entretiens, nous avons pu collecter de nombreuses informations sur le fonctionnement des jardins partagés, tant bien concernant leur mise en place que leur fonctionnement. Certains jardins fonctionnent grâce à un animateur technique qui gère le planning et la gestion au quotidien. C’est lui qui va assigner les différentes tâches aux bénévoles. Lorsqu’un animateur non technique s’occupe d’un jardin, celui-ci va plutôt se diriger vers la mise en place d’activités et d’animations afin de fédérer un maximum d’habitants du quartier. La problématique principale que nous avons pu extraire de nos différents entretiens avec des animateurs est la difficulté de fédérer des bénévoles sur le long terme surtout lorsqu’il n’y a pas d’animateur technique présent dans le jardin.

Enfin, le troisième type d’acteur que nous avons rencontré est les bénévoles. Nous avons rencontré deux bénévoles, Alice et Marianne, deux retraités qui aiment jardiner et qui participent au jardin partagé de leur quartier. Leur objectif principal est de passer un moment convivial et en plein air chaque semaine. Elles nous ont tout de même partagé les difficultés qu’elles peuvent rencontrer lorsque la dynamique au sein des bénévoles et l’organisation du jardin ne sont pas au point. Il peut être compliqué de rester fidèle à un jardin où il n’y a pas d’animateur puisque cela engendre un manque d’organisation sur le court et long terme. La planification d’un jardin peut se faire sur un ou deux ans avec différentes phases de repos et de culture de la terre.

En somme, les entretiens suggèrent que le succès des jardins partagés repose en grande partie sur la présence d’une structure d’accompagnement, telle qu’une association, ainsi que d’un animateur. Ces éléments permettent de mobiliser la communauté, de créer des liens sociaux et d’assurer un fonctionnement efficace. Les jardins partagés peuvent ainsi remplir leur double objectif : promouvoir des pratiques durables tout en renforçant les liens sociaux au sein de la communauté. Cependant, cet accompagnement nécessite des fonds et n’est donc pas présent dans de nombreux jardins. Nous avons donc choisis dans le cadre de notre projet de nous intéresser à ces jardins partagés qui font face à davantage de difficultés afin de trouver une solution pour faciliter leur organisation et leur permettre de fédérer plus d’habitants.

 

Partie 2 – Persona

Suite à nos entretiens, nous avons traduit les données recueillies sous la forme de profils types d’utilisateurs : les persona. 

Rachelle fait partie de la classe active, elle représente les personnes faisant parties d’organisations actrices des jardins. Le bon fonctionnement du jardin est l’une de ses responsabilités.

Fig. 2 : Persona Rachelle

Les deux persona suivants représentent les utilisateurs, dans leur diversités de motivations, de caractères et de connaissances.

Fig. 3 : Persona Marianne

Fig. 4 : Persona Pierre

 

Partie 3 – Exemples de guide d’entretien

 

Guide d’entretien pour un animateur :

Thème 1 : Mise en place

• Comment s’est passée la mise en place du jardin collectif du square Jules Le Gall?
• Comment se passe la mise en place des jardins vis à vis de la législation? 
• Quelles sont les personnes concernées ?  Quels sont les acteurs ?
• Quel est ton rôle dans la mise en place des jardins ?

Thème 2 : Organisation

• Comment fais-tu pour communiquer sur le jardin ?
• Comment sera décidé qui sera l’animateur du jardin ?
• Quelles sont tes difficultés en ce moment ?
• Comment gères-tu tes différents projets ? Combien en as-tu en parallèle ? 
• Comment envisages-tu la gestion des jardins sur le long terme?

 

Guide d’entretien pour les bénévoles :

Thème 1 : Qui sont-ils?

• Présentez vous rapidement
• Comment avez-vous découvert le jardin / l’association? 
• Pourquoi y venez-vous? A quelle fréquence ?
• Pourquoi ce type de lieu par rapport aux espaces verts de la ville?

Thème 2 : Le jardin et l’organisation

• Comment trouvez-vous les informations concernant les activités / animations?
• Point forts/faibles?
• Le recommandez-vous à d’autres personnes ?
• Est ce que vous allez loin de chez vous?
• Quelle est la superficie du jardin ?
• Avez-vous des photos du jardin ?
• Comment les ressources sont-elles gérées ?

 

Guide d’entretien pour les responsables des espaces verts de Brest métropole :

Thème 1 : Les espaces verts

• Quels sont vos objectifs? (mixité sociales)
• Comment vous organisez-vous ?
• Pouvez-vous nous parler d’un projet ?
• Comment sont gérées les ressources (eau, matériel)?

Thème 2 : Les jardins partagés

• Comment se passe la mise en place d’un nouveau jardin?
• Des contraintes législatives ?
• Difficultés à monter une équipe autour d’un jardin?
• Difficultés à avoir des financements?
• Comment sont gérées les ressources (eau, matériel)?

Thème 3 : Politique

• Comment les projets sont-ils choisis ?
• Difficultés à avoir des financements?
• Quelles sont les réglementations en vigueur vis-à-vis des espaces verts/espaces partagés dans les villes?
• Comment répartissez vous le travail d’un projet (embauche? / création d’emploi/d’équipes)

 

PharmaBox – enquête terrain

Envoyé par a21derri le 27 Oct 2023 dans TAF COUAD | 0 commentaire

Auteurs :

• Adam Giovanni
• Michael Moreno
• Alexandre Derrien
• Romain Boinet
• Fred N’guetta

 

Rappel de notre projet : 

Les premières idées que nous avons eu pour le projet SanS-T étaient trop larges. Certes nous avions défini un secteur : le monde hospitalier. Cependant, ce dernier était assez vague et  ne nous permettait pas d’énoncer une problématique claire. En effet le monde hospitalier rencontre des problèmes diverses : manque de personnel, surcharge de travail, gestion des stocks de médicaments difficile ou même la gestion administrative. Afin d’avancer efficacement il fallait nous concentrer sur un aspect plus précis. Rapidement nous avons choisi de nous focaliser sur un corps de métier présent à l’hôpital : le personnel infirmier. Notre problématique est de trouver un moyen d’automatiser certaines tâches effectuées par le personnel infirmier afin pouvoir économiser leur temps de travail.

Nous avons décidé de nous intéresser à une tâche précise du métier d’infirmier : l’administration de médicament. Le processus de prise de médicaments à l’hôpital commence par la prescription médicale du médecin, suivie de la transcription par le personnel de santé dans le dossier du patient. Les médicaments sont ensuite préparés par la pharmacie, administrés par le personnel infirmier conformément aux horaires prescrits, et chaque administration est consignée dans le dossier médical du patient. 

Nous avons imaginé une solution : la PharmaBox. Il s’agirait d’une armoire automatisée qui prendrait en charge la distribution de médicament dit ‘’ordinaire’’. L’objectif serait d’avoir une application dans laquelle un patient pourrait demander un médicament, en fonction du profil le personnel infirmier en charge du patient pourrait accepter ou refuser la demande. Si la demande est validée, le patient peut ensuite aller se servir tout seul son médicament. Nous pensons que nous pouvons également utiliser cet outil pour éduquer un patient à la posologie de son futur traitement. 

Toujours dans une logique de précision, nous pensons qu’il est important de se restreindre à un unique service dans un premier temps. De nos connaissances personnelles, la traumatologie est un service où la prise de médicaments “ordinaires” type antalgique est fréquente. Les patients de ce service sont également sujet à des traitements qui se poursuivent après l’hôpital, ce qui rend intéressant la logique d’éducation évoquée précédemment. 

Afin d’évaluer si notre idée répondait à un réel besoin de la profession nous avons établi un certain nombre d’hypothèses que nous avons cherchées à valider au travers d’une enquête terrain.

Hypothèses : 

H1 : Les infirmières en milieu hospitalier ont une surcharge de travail qui les empêche de passer du temps avec leurs patients. 

Cette hypothèse part du principe que les infirmières en milieu hospitalier sont débordées par le nombre trop important de patients dont elles doivent s’occuper. Elles sont donc constamment sous pression pour passer dans chaque chambre prévue dans leur planning. Par conséquent, elles n’ont pas le temps d’échanger avec le patient. Le côté social de la profession, qui pour la plupart du personnel infirmier est la raison du choix de ce métier, s’en trouve terriblement fragilisé.

H2 : L’administration de médicament est une tâche prépondérante du métier d’infirmier 

L’administration de médicaments fait partie intégrante des responsabilités infirmières et nécessite une formation appropriée pour assurer la sécurité et le bien-être des patients. Les infirmières sont souvent chargées de distribuer et administrer les médicaments selon les ordonnances médicales, tout en suivant des protocoles stricts pour éviter les erreurs.

H3 : La prise d’antalgiques et les traitements post-hôpital sont fréquents dans le service traumatologie de l’hôpital. 

Cette hypothèse énonce 2 idées : 

• Les patients du service traumatologie sont souvent sujets à la douleur et réclament donc souvent des antalgiques. 
• Les traitements de ce service se poursuivent souvent après la sortie du patient de l’hôpital

 

H4 : Les infirmières du service traumatologie de l’hôpital souhaitent éduquer leurs patients à la prise d’un traitement qui se poursuivra après la sortie de l’hôpital mais ne possède pas d’outil adéquat.

Cette hypothèse stipule qu’il est important pour les infirmières du service traumatologie de l’hôpital d’éduquer les patients à la posologie d’un traitement. En effet, si ce dernier continue après la sortie de l’hôpital et que sa prise est aisée, il est nécessaire que le patient soit autonome. Néanmoins, dans l’état actuel des choses, nous pensons que les infirmières ne possèdent ni l’outil ni le temps nécessaire à cette éducation. 

H5 : Les patients du service traumatologie de l’hôpital ont souvent besoin d’antalgiques.

Cette hypothèse repose sur l’idée que les blessures dont souffrent les patients du service traumatologie de l’hôpital sont causes de douleurs. Ces dernières peuvent être soulagées par la prise d’antalgique ou d’anti-douleurs. 

H6 : Les patients du service traumatologie de l’hôpital sont capables de prendre des traitements simples seuls. 

Cette hypothèse suggère que la prise de certains traitements ou médicaments est aisée. D’un point de vue pratique, le patient peut donc les prendre en autonomie sans forcément avoir besoin d’une infirmière dans sa chambre. 

H7 : Les patients d’un hôpital sont capables d’utiliser une application web simple. 

Cette hypothèse émet l’idée que les tous les patients d’un hôpital, même les plus âgés, n’ont pas de difficulté pour utiliser une application web simple qui demande seulement une connexion et la sélection de certains boutons. 

H8 : Une chambre d’hôpital peut aisément accueillir et alimenter une boîte de taille moyenne.  

Cette hypothèse repose sur le fait qu’il est possible d’intégrer à un hôpital une boîte de taille moyenne, c’est-à-dire un volume maximum de 0,027 m3. Celle-ci pourra par exemple être posée à côté du lit et être alimentée à l’aide d’une prise classique (220V).

Les différents acteurs : 

Déroulé des entretiens 

La plupart des personnes que nous avons interviewé étaient contentes de parler de leur métier et de partager leurs expériences. En règle générale, nos entretiens ont duré une trentaine de minutes et se sont déroulées de la manière suivante : 

• Questions à propos du parcours scolaire et professionnel 
• Questions sur leur métier ou sur les métiers de la santé 
• Exposition de nos hypothèses afin d’obtenir leur point de vue
• Courte phase de questions pour revenir sur certains points de l’entretien si besoin

Liste des personnes interrogées

Nom : Mme Latouche.

Profession : Enseignante chercheuse en économie et droit de la santé et innovation

Caractéristiques : Son activité, hors enseignement, consiste à évaluer de l’extérieur les projets innovants en santé. 

Principaux enseignements : 

Mme Latouche étant la première personne que nous avons interviewé, elle nous a permis de poser un cadre contextuel fort et nous a partagé son avis sur les besoins à l’hôpital tout en nous rappelant qu’elle n’était pas infirmière et que par conséquent il était nécessaire de confirmer ses dires par un.e infirmier.e qui est bien plus proche de la réalité. Elle a beaucoup insisté sur l’organisation de l’hôpital qu’elle qualifie de “défaillante”. Elle nous a également parlé de la notion de chaîne du patient, qui fait référence au parcours complet d’un patient à travers le système de soins de santé. Elle nous a également fait part du processus d’un projet d’innovation en santé qui se décrit comme suit : 

Hypothèse, identification de besoin, idéation, prototypage, étude clinique (efficacité d’un point de vue patient), étude économique. Enfin, fort de sa grande expérience, elle nous à partager plusieurs de ses contacts qu’il serait pertinent pour nous d’interviewer dans le cadre de notre projet.

Nom : Mr Delorme.

Profession : Directeur des services numériques d’un CHU (Centre Hospitalier Universitaire)

Caractéristiques : Mr Delorme est une personne assez directive et pressée. Il se tient à jour sur les innovations dans le milieu de la santé et a été porteur de plusieurs projets au sein de CHU dans lequel il travaille. Il adore l’innovation tout en ayant un regard très pragmatique sur les réels besoins du secteur hospitalier, pour lui, l’innovation doit toujours être motivée par un besoin précis.

Principaux enseignements : 

Au cours de l’entretien, Mr Delorme nous a parlé plus en détail des différents outils existants et nous a fourni beaucoup de sources à propos de solutions impliquant des objets communicants. Quand nous lui avons présenté nos hypothèses, il nous a conseillés de préciser plus le périmètre d’étude. De plus, il nous a appris que le contexte réglementaire était assez fort à l’hôpital, qui pouvait parfois entraver le développement de l’innovation à l’hôpital. Lors de notre entretien, nous avons évoqué avec lui la solution que nous avons envisagée. Il nous a dit que des armoires à pharmacie connectées existent déjà et étaient notamment utilisées dans le milieu carcéral. 

Nom : Mme Lilas.

Profession : Infirmière dans un service recevant des patients de chirurgie cardiaque.

Caractéristiques : Jeune infirmière diplômée depuis 3 ans, Mme Lilas a choisi d’être infirmière car c’est un métier qui adhère à ses valeurs, elle aime aider les gens et sentir que son métier est utile. Elle apprécie également la diversité offerte par ce métier. 

Principaux enseignements : 

Dans cet entretien, il était essentiel que nous apprenions quelles sont les tâches d’une infirmière qui travaille dans un service hospitalier. Sa journée type se déroule de la manière suivante : Elle est parfois dans le service avec les patients, elle va donc administrer les soins, distribuer les médicaments et surveiller les patients de son service. Elle travaille également sur les soins de pansement et assiste à des consultations de patients. Nous l’avons ensuite interrogé sur les difficultés qu’elle rencontrait dans son métier. Elle a évoqué la surcharge de travail, les interruptions à cause de son téléphone qui sonne, ainsi que le temps passé sur les tâches ou elle ne pense pas être nécessaire comme la prise de rendez-vous. Elle souhaiterait voir sa charge de travail allégée afin de pouvoir passer plus de temps avec ses patients, elle est convaincue que cela aide aussi à la guérison du patient.

Mme Lilas nous a expliqué que quand elle délivrait un médicament, elle engageait sa responsabilité en tant qu’infirmière, par ailleurs, elle trouve la distribution de médicament génériques qui peuvent s’obtenir sans ordonnance est une tâche redondante. Enfin, elle nous a confié qu’il était parfois dur pour elle d’expliquer à ses patients pourquoi leur traitement est important et que si elle pouvait passer plus de temps avec eux, cela ne serait pas un problème. 

Nom : Mr Calvin

Profession : Chef de projet innovation au sein d’un incubateur spécialisé dans la santé.

Caractéristiques : Mr Calvin est nouveau à son poste au sein de l’incubateur, il est là pour faire la passerelle entre les startups et le CHU afin de trouver des terrains expérimentaux et des projets qui ont du potentiel afin de les accompagner avec l’incubateur.

Principaux enseignements : 

Nous avons questionné Mr Calvin sur les tendances en innovation dans le secteur de la santé, il nous a répondu qu’il y avait beaucoup de solutions développées car c’est un secteur qui évolue beaucoup notamment grâce au développement de nouvelles technologies (ex : Intelligence Artificielle), bien que le secteur puisse être par moments réticents aux changements. 

Ensuite il nous a parlé des challenges du numérique en santé. Pour lui, et d’après ses observations, l’innovation en santé doit soit améliorer le soin, soit améliorer la connaissance de la maladie. De plus, la tendance est aussi à la qualité de vie au travail des soignants, ainsi qu’à la relation patient soignant. Le fait qu’il y ait de moins en moins de personnel nécessite donc de dégager du temps pour les mobiliser sur des tâches à forte valeur ajoutée. De plus, il nous a également dit que la responsabilisation du patient face à sa maladie était très importante et que cela nécessite une grande attention. Après lui avoir présenté brièvement notre solution, il nous a également conseillé de nous tourner vers les EHPAD, car les résidents sont plus friands de technologie que ce que l’on pense et que le personnel fait aussi face à des contraintes de travail assez fortes.

Nom : Mme Neige

Profession : Infirmière en service de traumatologie dans un CHU.

Caractéristiques : Mme Neige a obtenu son diplôme et a commencé à exercer en traumatologie il y a 3 ans. Elle a déjà réalisé plusieurs tâches dans des services différents lors de ses études. Elle apprécie en particulier le côté social de son métier.

Principaux enseignements : 

Au cours de cet entretien, il nous semblait essentiel de comprendre comment se déroule une journée dans un service de traumatologie et quels sont les types de patients qui y sont soignés. Le service de traumatologie regroupe des patients qui doivent bénéficier d’une prise en charge chirurgicale des suites d’un accident (qu’il soit plus ou moins grave). Les patients sont hospitalisés avant et après chirurgie dans ce service. 

La journée d’une infirmière dans ce service se déroule généralement de la manière suivante : 

• Transmissions inter-équipes
• Distribution des médicaments (notamment des anti-douleurs) et prise des paramètres vitaux des patients du service 
• Soins particuliers des patients (injections, pansements, perfusion)
• Visite des patients avec le médecin
• Accueil et sortie des patients 

La plupart de ces tâches sont à effectuer en parallèle, ce qui constitue une difficulté supplémentaire selon Mme Neige. Elle a insisté sur le fait qu’il est compliqué d’attribuer une importance à ces différentes tâches car elles varient en fonction des demandes, des besoin des patients, du nombre de patients dans le service, ou bien si l’équipe avant à accumulé du retard suite à une entrée d’un patient qui n’était pas prévu par exemple, il faut donc pouvoir s’adapter au mieux car chaque minute compte.  Dans les services de traumatologie, une infirmière à la responsabilité de 10 à 15 patients mais peut en pratique s’occuper d’autres patients pour soulager un/une collègue qui prendrait du retard.

Dans ce service, l’interruption des tâches est omniprésente en raison de la sollicitation importante de l’infirmière (changement de traitement d’un patient, demande d’aide d’une collègue, sollicitation d’un patient à cause de ses douleurs).

Le but de la prise en charge après l’opération dans ce service est de rendre autonome le patient avant son retour à domicile (gestion des traitements, récupération de la mobilité, gestion de la douleur).

Dans les services de traumatologies, les patients quittent régulièrement l’hôpital avec un traitement conséquent qu’ils doivent apprendre à gérer seuls, généralement les traitements durent en moyenne 1 mois. 

Mme Neige aimerait avoir davantage de temps à passer auprès de ses patients pour les rassurer, les renseigner et pouvoir établir une relation de confiance, ce qui représente le cœur de son métier selon elle.

Lorsque nous l’avons interrogé sur notre première idée de solution, notamment sur les dimensions de l’objet que nous avons imaginé, Mme Neige était plutôt confiante et nous a dit que dans son service, les chambres ont suffisamment de place pour recevoir des petits modules qui font approximativement la taille d’une boîte à chaussure. Selon elle, le plus dur est de trouver une place à laquelle la boîte est facilement accessible pour tous les patients.

 Nom : Mme Lana

Caractéristiques : Mme Lana s’est faite hospitalisée suite à une intervention. Elle n’est pas habituée à prendre des médicaments au quotidien.

Principaux enseignements : 

Mme Lana a dû être opérée suite à une chute sur son genou. Elle a passé 6 jours à l’hôpital entre son arrivée aux urgences et sa sortie après son opération. Durant ces 6 jours, Mme Lana, est passée par diverses émotions et épreuves. Évidemment la douleur à cause de sa blessure était gênante, mais cela s’est ajouté à du stress à cause de l’opération puis des douleurs post-opératoires. Mme Lana a passé 4 jours en convalescence après l’opération, et a dû apprendre à faire face à son traitement. 

Elle a entre autres remarqué que le personnel soignant paraissait débordé et l’infirmière a  plusieurs fois été interrompue lors de ses visites. Elle est rentrée chez elle avec un traitement qu’elle ne connaissait pas bien (piqures d’anticoagulant, antalgiques, protecteurs gastriques, anti-inflammatoires, vitamines) et elle pense qu’elle aurait mieux vécu son retour à domicile si elle avait été mieux éduquée face à son traitement. Elle dit s’être renseignée sur internet une fois chez elle car elle n’a pas osé poser les questions à l’équipe soignante, ayant peur de les déranger.

Les enseignements clefs de nos entretiens : 

Afin de tirer les bons enseignements de nos entretiens il est nécessaire de les diviser en deux parties. Les entretiens menés auprès de potentiel utilisateurs (i.e le personnel infirmier et le patient) et des entretiens menés auprès de professionnels faisant partie de l’écosystème de l’hôpital. 

Les entretiens avec le DSI du CHU, l’enseignante chercheuse et le membre d’un incubateur spécialisé dans le secteur de la santé nous ont permis de :

• Développer nos connaissances des différents acteurs et système d’information d’un hôpital
• Confirmer la difficulté d’innover dans ce secteur, assez réticent au changement dû à la législation
• Confirmer la nécessité de développer des solutions qui s’imbriquent dans le système d’information d’un hôpital
• Ne pas oublier qu’une solution ne doit pas détériorer la qualité de soin des patients 

Les entretiens avec le personnel infirmier nous a permis de valider certaines hypothèses :

• Le personnel infirmier fait en effet face à une surcharge de travail. A cette surcharge de travail s’ajoutent des appels téléphoniques pour répondre à différents besoins :  demande de patients, coordination entre les différents services etc… 
• L’administration de médicament est effectivement une tâche récurrente et importante dans le quotidien du personnel infirmier
• Au sein du service traumatologie de nombreux patient sont amené à suivre des traitements longs suite à leur séjour à l’hôpital 
• Au sein du service traumatologie il y a effectivement beaucoup de demandes autour de la gestion de la douleur, cependant les patients ne sont pas forcément très mobiles et autonomes. 

Les entretiens avec le patient a mis en évidence :

• La nécessité de bien former les patients à l’usage de leur traitement 
• La conscience des patients envers la surcharge de travail du personnel infirmier 

Personas : 

Ces deux personas et leurs caractéristiques représentent une synthèse des informations que nous ont partagé les personnes que nous avons pu interviewer. Le personnel infirmier est  décrit via le persona de Sarah, qui est surchargée dans son travail, qui souhaite plus de temps qualitatif avec ses patients et qui aimerait que ses compétences soient mieux mobilisées afin qu’elle ne soit interrompue que lorsque l’on a besoin de ses compétences d’infirmière. Le persona de Vincent est inspiré principalement de l’interview que l’on a pu faire avec une patiente hospitalisée suite à une chute, qui nous a partagé son ressenti lors de son hospitalisation et les problèmes qu’elle à pu rencontrer. L’entretien avec le chef de projet innovation au sein d’un incubateur nous à également permis de travailler sur ce persona car il nous a parlé de la relation entre patient et soignant ainsi que de la responsabilisation du patient face à sa maladie.

Conclusion : 

Notre enquête terrain nous a permis dans un premier temps de cartographier les différents acteurs qui interviennent lors de la prise en charge d’un patient et par conséquent de mieux comprendre les enjeux et les exigences. Ensuite, nous avons appris des choses sur différents volets, l’un concernant le coeur du métier infirmier et la gestion des patients grâce aux entretiens avec les deux infirmières et la patiente, puis deuxièmement, nous avons aussi appris des choses au sujet de l’innovation dans le milieu de la santé, ce qui nous permet désormais de comprendre à quoi elle doit répondre mais également comment les solutions innovantes doivent tenir compte des contraintes particulières propre à ce milieu. Nous avons enfin pu cibler un service en particulier et allons penser à notre solution dans un service de traumatologie, nous gardons pour autant à l’esprit que notre solution pourrait s’inscrire plus largement dans d’autres services, ou bien même dans d’autres établissement des soins comme les EHPADs. Grâce à notre enquête terrain, nous sommes désormais certains d’élaborer une réponse appropriée en accord avec les attentes et les circonstances sur le terrain.