Actualités Projets

Mini-projet capteur météo et LoRaWAN avec la Lopy4

Envoyé par le 18 Oct 2021 dans Projets, TAF CoOC | 0 commentaire

Dans ce mini-projet, il s’agit de transmettre les informations de température et hygrométrie d’une pièce à un serveur du réseau The Things Networks à l’aide à l’aide du protocole LoRaWAN.

Sommaire

Etape 1 Accéder au réseau The Things Network (TTN)

Etape 2 Récupérer les données de température et humidité du DHT11

Etape 3 Envoi des données de température et humidité sur le serveur TTN

Matériel/logiciel :

  • LoPy4 + Expansion Board 3.1 de Pycom
  • Antenne LoRa
  • Capteur de température DHT11
  • Des fils
  • Gateway LoRaWAN en fonctionnement et à proximité qui permet la couverture réseau, existante ou à fabriquer soi-même (tuto à venir …)
  • VSC ou Atom pour la programmation en python

Etape 1 Accéder au réseau The Things Network (TTN)

a) Découverte du réseau TTN et de la plateforme web

La figure 1 présente l’architecture classique d’un réseau LoRaWAN, dite en étoile. Chaque noeud (ou end device) peut être connecté à plusieurs passerelles (gateways), qui sont elles-mêmes connectées à un serveur d’application qui va collecter, choisir voire, traiter les données. Les gateways ne font que relayer les paquets de données. Si le serveur d’application reçoit plusieurs fois le même paquet en provenance de plusieurs passerelles, il est  capable de choisir celui avec la meilleure qualité de signal.

FIG 1. Par Germain GAUDARD — Travail personnel, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=64159124

Il existe plusieurs réseaux publics d’opérateurs LoRaWAN. Dans ce mini-projet, nous choisissons le réseau The Things Network (TTN), qui est un réseau public open-source, qui peut être utilisé sans contrainte commerciale ou privée.

L’équipe pédagogique a préalablement déclaré les noeuds LoPy4 sur l’interface de TTN appelée, The Things Stack Community Edition.

Exemple de tutorial pour déclarer un device de type LoPy4 (lien vers tuto spécifique).

Demandez login et mdp à l’enseignant.e présent.e pour accéder à la plateforme [4].

Les devices sont nommés selon leur adresse MAC (voir Bien démarrer avec la LoPy4 pour lire l’adresse MAC). Avant toute chose identifiez votre device en lisant son adresse MAC.

Dans l’application tp-lora-cooc de la plateforme The Things Stack Community Edition [4], repérez votre device et cliquez pour obtenir des informations supplémentaires :

 

Notez la valeur de AppEUI, DevEUI et AppKey. Les 3 éléments permettent de mettre en place une connexion LoRaWAN sécurisée avec le serveur TTN.

Dans l’onglet Live data, vous observerez plus tard les données qui sont remontées de votre noeud (uplink) ou qui sont envoyées à votre noeud (downlink). Dans l’onglet Messaging, vous pouvez simuler l’envoi de données uplink au serveur, vous pouvez également programmer des envois de données downlink. Vous pouvez également appliquer un code aux données reçues et envoyées permettant de les formatter pour les rendre lisibles par un humain (Payload formatters).

Toutes ces actions seront expérimentées un peu plus loin.

b) Se connecter au réseau TTN à partir de votre LoPy4 et envoyer vos 1ers paquets

Vous allez connecter votre Lopy4 au réseau TTN et envoyez vos 1ers paquets en uplink sur le réseau TTN. !! N’oubliez pas de connecter l’antenne LoRa !!

  • Récupérez le code main_template.py sur gitlab [5]
  • Modifiez DevEUI et AppKey selon les paramètres indiqués sur la plateforme TTN
  • Modifiez le nom en main.py et Lancez un RUN
  • Observez les print dans la console ainsi que la couleur de la LED qui vous indique l’évolution de la connexion
  • Une fois la connexion effectuée (CONNECTED!!), observez les messages remontés sur la plateforme dans l’onglet Live data

Quelle est la forme des paquets remontés ?  Quel est le lien avec le format de données de votre code python ?

Quel est l’impact du data rate (DR) sur l’envoi des paquets ? Commencez par un DR égal à 4 (SF8BW125)  puis passez à 0 (SF12BW125) [6].

Quel est l’impact du DR sur le timeonair ? utilisez lora.stats() et/ou lisez la variable consumed_airtime sur la plateforme en cliquant sur l’évènement (event details)

Quel est le SNR de la transmission ? lisez la variable SNR dans l’onglet Live data. Observez les variations (min/max).

Calculez la marge de transmission pour le min et le max, pour chaque DR. (Cf. [7] video 17 slide 16 et vidéo 16 slide 4, supports disponibles en pdf sur Moodle)

c) Récupérer des paquets du serveur TTN vers votre Lopy4 (Downlink)

Pour cela, nous allons programmer des envois downlink à partir de la plateforme TTN, onglet Messaging du device.

  • Décommentez les lignes de code correspondantes à la réception d’un message sur la LoPy4
  • Après avoir ré-initialisé votre LoPy4 (soft reset, ctrl+F ou ctrl+alt+F), relancez un RUN
  • Après la connexion, observez la réception du 1er paquet sur l’interface, puis la LoPy est en attente de réception d’un paquet
  • Programmez un envoi downlink (exemple FF)

  • Observez la réception du paquet sur la LoPy, puis l’envoi d’un nouveau paquet en uplink.

L’attente de réception d’un paquet bloque l’envoi de tout nouveau paquet.

Etape 2 Récupérer les données de température et humidité du DHT11

Pour cette étape, nous allons utiliser la LoPy4 uniquement en tant que micro-contrôleur (pas de transmission sans fil) pour récupérer les données du capteur de température et humidité DHT11. La data sheet du capteur est donnée ici [2]. Il est monté sur une carte à 3 broches SE052, dont la data sheet est donnée ici [8].

  • Récupérez le dossier DHT11 sur gitlab [9]
  • Dans le main.py, identifiez la broche de la LopY qui sera utilisée
  • Branchez les fils entre le capteur DHT11 et la LoPy4. S pour signal, – pour GND, VCC sur la broche du milieu
  • Lancez un UPLOAD (car il faut charger la librairie dht.py)
  • Observez les données récupérées
  • Dans le fichier dht.py, lisez le code correspondant à read(). Comparez avec le chronogramme de  communication ci-dessous (extrait de la data sheet [2]). Qu’observe-t-on en sortie de la fonction pulses_get() ? Quels sont les intervalles de temps qui permettent de définir si le capteur envoie un ‘0’ ou un ‘1’ ?

Chronogramme de communication entre DHT11 et MCU

  • Repérez le format des données dans la data sheet, comparez avec le code read(). Combien d’octets sont envoyés ? Quels sont les octets qui contiennent les données ? À quoi sert le checksum ?

 

Etape 3 Envoi des données de température et humidité sur le serveur TTN

Nous allons maintenant intégrer les 2 codes précédents pour envoyer les données de température et humidité sur le serveur TTN.

a) Intégration des 2 codes précédents

À vous de jouer !

Attention au format des données transmises via LoRaWAN. Utilisez la fonction bytes() pour envoyer des octets.

La table de correspondance Decimal <>Hexadecimal<>Caractère ASCII [10] peut vous aider.

Vous devriez voir apparaître quelque chose comme ça dans la console TTN de votre device

Observez le format affiché des données reçues (MAC Payload : 1549).

Comparez avec le format affiché des données envoyées :

Temp : 21

RH : 73

b’\x15I’

b) Mise en forme des données affichées dans la console : Payload Formatters

Dans l’onglet Payload Formatters de votre device, choisissez Formatter Type > Javascript. Appliquez directement la fonction telle qu’elle est proposée (Save changes) et observez le résultat dans la console. Vous pouvez aussi tester vos modifications dans la fenêtre Test en appliquant une valeur dans Byte payload.

Puis modifiez la fonction decodeUplink pour permettre l’affichage sous la forme suivante :

Conclusion

Bravo ! Vous êtes allés au bout de ces 3 activités autour de la prise en main des LoPy4 !

Il reste encore plein de choses à découvrir dans le monde de l’IoT. Voici quelques pages d’inspiration :

  1. un projet très complet qui envoie les données d’une station météo sur la plateforme cloud Ubidots (via WiFI) en utilisant le protocole MQTT (Message Queuing Telemetry Transport), puis envoi des données sur une application Android [11]
  2. un autre projet du même style mais qui utilise plutôt la plateforme cloud IFTTT, en utilisant l’application IFTTT (dans tous les stores) [12]
  3. un projet de capteurs pour les plantes qui utilise la plateforme de Pycom, appelée Pybytes, à l’aide d’une connexion WiFI [13]

Plus d’infos sur les plateformes Cloud Ubidots [14] ou Cayenne [15].

 

Références

[1] « Démarrer avec Lopy4 Pycom | Téléfab ». https://telefab.fr/2021/09/27/demarrer-avec-lopy4-pycom/ (consulté le oct. 19, 2021).

[2] « DHT11.pdf · main · LANGLAIS Charlotte / TP lora COOC », GitLab. https://gitlab.imt-atlantique.fr/clanglai/tp-lora-cooc/-/blob/main/DHT11.pdf (consulté le oct. 19, 2021).

[3] « TTN Mapper ». https://ttnmapper.org/colour-radar/ (consulté le oct. 19, 2021).

[4] « Management platform for The Things Network », The Things Network Console. https://eu1.cloud.thethings.network/console (consulté le oct. 19, 2021).

[5] « OTAA/main_template.py · main · LANGLAIS Charlotte / TP lora COOC », GitLab. https://gitlab.imt-atlantique.fr/clanglai/tp-lora-cooc/-/blob/main/OTAA/main_template.py (consulté le oct. 19, 2021).

[6] « LoRa ». https://docs.pycom.io/firmwareapi/pycom/network/lora/ (consulté le oct. 19, 2021).

[7] « Mobilefish.com – LoRa/LoRaWAN tutorial. » https://www.mobilefish.com/developer/lorawan/lorawan_quickguide_tutorial.html (consulté le oct. 19, 2021).

[8] (C) 2020 Conrad, « Iduino Module capteur d’humidité 1 pc(s) SE052 | Conrad.fr ». https://www.conrad.fr/p/iduino-module-capteur-dhumidite-1-pcs-se052-1485325 (consulté le oct. 19, 2021).

[9] « DHT11 · main · LANGLAIS Charlotte / TP lora COOC », GitLab. https://gitlab.imt-atlantique.fr/clanglai/tp-lora-cooc/-/tree/main/DHT11 (consulté le oct. 19, 2021).

[10] « Fichier:ASCII-Table-wide.svg — Wikipédia ». https://commons.wikimedia.org/wiki/File:ASCII-Table-wide.svg(consulté le oct. 19, 2021).

[11] « Tutorial on how to build a Pycom LoPy4 weather station », HackMD. https://hackmd.io/@ehTrKNe5RYyySf6QXbWMWA/ByVCoGFAU (consulté le oct. 19, 2021).

[12] « Automating a floor fan with DHT11 sensor », HackMD. https://hackmd.io/@abbeabbe/ByNXPfGyv (consulté le oct. 19, 2021).

[13] « Plant Sensor », Hackster.io. https://www.hackster.io/55480/plant-sensor-a9937f (consulté le oct. 19, 2021).

[14] « Ubidots ». https://www.thethingsindustries.com/docs/integrations/cloud-integrations/ubidots/ (consulté le oct. 19, 2021).

[15] « Cayenne ». https://www.thethingsindustries.com/docs/integrations/cloud-integrations/cayenne/ (consulté le oct. 19, 2021).

 

Projet CODEV n°28 : Coupe de France de robotique

Envoyé par le 18 Oct 2021 dans Projets | 0 commentaire

Nous sommes trois étudiants en FISE A1 et dans le cadre de notre projet CODEV, nous avons collaboré avec le club de robotique d’IMT Atlantique en vue de sa participation à l’édition 2021 de la Coupe de France de robotique qui se déroulera début juillet. Notre projet s’est donc inscrit donc dans un projet plus large, celui d’engranger le plus de points possible lors de l’édition 2021 de la compétition et de remettre en place les bases techniques et matérielles qui seront utiles lors des éditions futures de la coupe.

 

Le déroulement d’un match de la Coupe de France de robotique peut se résumer de la façon suivante : deux équipes s’affrontent en plaçant un ou deux robots (et parfois des systèmes électroniques secondaires) sur une aire de jeu afin d’engranger un maximum de points en 100 secondes.

 

Aire de jeu de l’édition 2021 de la coupe

 

Notre travail s’est concentré sur la conception et la fabrication du phare, un système annexe au robot principal de l’équipe qui peut rapporter jusqu’à 15 points sur les 93 points disponibles au maximum (sans compter les bonus). Le phare doit être placé par l’équipe dans une zone de l’aire de jeu appelée “zone rocheuse” et doit être allumé au cours du match par un système impliquant un contact physique avec un des robots de l’équipe. Une fois allumé, il doit se déployer et allumer une source lumineuse avec balayage pour signaler la zone rocheuse. Ce système est également soumis à de nombreuses contraintes (dictées par le règlement de la coupe[1]) portant sur ses dimensions, son amplitude de déploiement, son système d’éclairage ou encore son alimentation. Cependant, nous étions  très libres au niveau du choix de la méthode de déploiement du phare. Le déploiement doit être déclenché par une action physique du phare, cependant il peut mettre en jeu un système purement mécanique (par exemple un système de ressorts) ou un ensemble mécatronique plus complexe. Au vu du temps nous étant accordé pour travailler sur ce projet, nous avons choisi de concevoir un phare basé sur un système mécatronique. La conception de ce type de système est particulièrement complexe, mais permet l’acquisition de compétences en électronique, en informatique mais également en mécanique, un sujet peu abordé en première année dans notre filière.

 

Notre travail s’est donc décomposé selon les étapes suivantes : nous avons tout d’abord longuement réfléchi sur la technologie de déploiement du phare, pour finalement aboutir à un mécanisme d’élévateur en ciseaux. La modélisation 3D du système à l’aide du logiciel de modélisation 3D Autodesk Inventor nous a ensuite  permis de dimensionner les différentes pièces et de valider de façon théorique certaines performances du phare.

 

 

 

 

  Modèle 3D

 

Après avoir obtenu un modèle 3D satisfaisant, il était nécessaire de réaliser un premier prototype d’un étage à l’aide d’une découpe laser et d’impressions 3D. Ce premier prototype a permis de souligner les défauts de notre modélisation en vue d’une amélioration de notre prototype. Finalement, nous avons pu fabriquer un prototype mécanique fonctionnel respectant la majorité des contraintes.

Prototype mécanique

 

Il ne nous restait donc plus qu’à mettre ce prototype en mouvement à l’aide du circuit électronique suivant, piloté par une carte Arduino Uno.

 

Voici donc le système final, dont nous sommes assez satisfaits car il respecte la majorité des contraintes fixées par le cahier des charges :

 

Au repos

 

 

Après déploiement

 

Il existe cependant certaines perspectives d’amélioration, avec notamment l’ajout d’étages supplémentaires au système (un étage correspondant à un « X » du système élévateur à ciseaux), l’ajout d’un pont en H permettant de contrôler la descente du phare et enfin la réduction des jeux de liaisons.

 

Nicolas Aïdoune, Yao-Hua Xu et Mouna Wamra.

Aller plus loin avec la LoPy4

Envoyé par le 4 Oct 2021 dans Projets, TAF CoOC | 0 commentaire

Voici quelques exercices pas à pas pour aller plus loin dans l’utilisation de la LoPy4 et la compréhension de la couche PHY du standard LoRa.

Si vous démarrez avec la LoPy4, consultez l’article Démarrer avec Lopy4 Pycom

Nous allons utiliser 2 LoPy4. l’une en émetteur, l’autre en récepteur.

Le code utilisé est celui du Ping Pong : Le code est disponible ici [1].

Si vous activez plusieurs transmissions en même temps, choisissez qui sera le noeud émetteur et le noeud récepteur et particularisez la transmission.

Exemple pour la transmission (binôme) A:

Côté émetteur

s.send('PingA')

Côté récepteur

s.recv(64) == b'PingA'

Les méthodes utilisées sont celles présenteés sur cette page [2]

À chaque modification du code, vous devez rebooter le device (ctrl+alt+f sur VSC ou ctrl+F sur Atom), puis relancer un run.

Utilisez la commande print pour voir l’effet de la modification des paramètres. Exemple :

print('Coding rate {}'.format(lora.coding_rate()))

1) Récupérer les paramètres LoRa d’une transmission

À partir de la méthode lora.stats(), récupérer les paramètres suivants :

Du côté de l’émetteur : spreading factor, puissance émise, fréquence utilisée, time on air

Du côté du récepteur : spreading factor, RSSI, SNR

Faire attention aux unités

À partir d’autres méthodes (à chercher sur  [2])

bande de transmission, coding rate, power mode, taille de préambule

2) Faire varier le RSSI

En modifiant l’environnement de transmission

Exemple 1 : antenne couchée ou debout

Exemple 2 : éloigner les 2 noeuds, placer les noeuds derrière des objets, etc

Laissez passer plusieurs trames, observez sur plusieurs trames avant de changer l’environnement

Quel impact sur le RSSI  côté récepteur ? Expliquez.

En arrêtant l’émission du Pong

Quel impact sur le RSSI côté émetteur  ? sur le sfrx ? sur le SNR ? Expliquez.

Vérifier les RSSI typiques

À l’aide des vidéos [3], vérifier que les RSSI observés sont typiques d’une transmission LoRa.

Toujours à l’aide des vidéos [3], comparez les RSSI observés avec les RSSI limite (receviez sensitivity). Attention au spreading factor utilisé.

3) Faire varier le time on air

Taille du message

Modifiez la taille du message envoyé pour faire varier le time on air. Expliquez.

À l’aide du calculateur https://loratools.nl/#/airtime [4]

comparez le time on air observé et le time on air calculé.

Observez le duty cycle pour la bande ISM Europe. Comment varie-t-il en fonction de la taille du message ? Pourquoi ?

Coding rate

Modifiez le coding rate à l’émetteur. Quel impact sur le time on air ?

Quel est l’intérêt d’un coding rate plus faible (1/2 par exemple) ?

4) Faire varier le spreading factor

Modifiez le spreading factor à l’émetteur : à partir du constructeur à l’initialisation, ou à partir de la méthode lora.sf()

Observez le récepteur. Pourquoi le message n’est-il pas reçu ?

Modifiez aussi le spreading factor du côté du récepteur.

Observez le time on air. Pourquoi double-t-il ?

Essayez de tirer des conclusions à partir de RSSI et SNR (pas facile du fait des variations de l’environnement de transmission  …)

 

[1] https://docs.pycom.io/tutorials/networks/lora/module-module/

[2] https://docs.pycom.io/firmwareapi/pycom/network/lora/

[3] https://www.mobilefish.com/developer/lorawan/lorawan_quickguide_tutorial.html

[4] https://loratools.nl/#/airtime

 

Démarrer avec Lopy4 Pycom

Envoyé par le 27 Sep 2021 dans Projets, TAF CoOC, Trucs & astuces | 0 commentaire

Un petit tutoriel pas à pas pour bien démarrer avec les cartes disponibles au fablab la Lopy4 de Pycom.
Plus d’infos  ici

et des tutos ici

Etape 1

https://docs.pycom.io/gettingstarted/software/vscode/

Installation de Visual Studio Code  et de l’extension Pymakr

qui permet de reconnaitre la carte.

MAJ du 23/09/21 : VSC 1.60 ne fonctionne pas avec Pymakr 1.1.13 (en attente de MAJ version). Utilisez une version downgrade 1.58 par exemple (June 2021), ainsi que Pymakr 1.1.12 (à récupérer directement dans l’onglet extensions de  VSC).

Selon la distribution Linux, peut nécessiter l’installation de pyserial.

Nécessite également NodeJS (sur Linux, à installer à partir d’un dépôt, sinon ici from the NodeJS website.).

Les PC du fablab sont déjà installés avec Visual Studio Code. Si nécessaire, installez l’extension Pymakr en la cherchant dans l’onglet des extensions.

Etape 2

suivre les instructions pour communiquer avec la carte et lancer un 1er programme en python directement sur la LoPy4 via le port USB.

https://docs.pycom.io/gettingstarted/

Etape 3 : tester des exemples

1er test : utiliser la led RGB disponible pour vérifier que vous pouvez charger un programme

Le code est disponible ici [1]

ATTENTION avant toute utilisation de la couche LoRA ou LoRaWAN, l’antenne  LoRa doit être branchée.

2e test : récupérer l’adresse MAC LoRa du noeud

from network import LoRa

import binascii

lora = LoRa(mode=LoRa.LORA, region=LoRa.EU868)

print(binascii.hexlify(lora.mac()).upper())

3e test :

Say Hello!, nécessite 2 LoPys (sans la couche LoRaWAN)

Le code est disponible ici [2]

Modifiez le code pour insérer l’adresse MAC du device dans le message envoyé.

Essayez avec plusieurs LoPy4 en même temps. Donnez un prénom anglais à votre device. Modifiez le code en insérant ce prénom dans le message.

4e test : le ping pong entre 2 LoPys (sans la couche LoRaWAN)

Le code est disponible ici [3]

Constructeur et méthodes en lien avec LoRa pour la LoPy4

Sur cette page [4], on trouve des méthodes permettant d’initialiser les paramètres LoRa de la LoPy et de récupérer ou de modifier un certain nombre de paramètres.

En mode LoRa (dit LoRa RAW ou LoRa MAC), identifiez les paramètres que vous pouvez modifier. Faites la même chose pour le mode LoRaWAN.

Raccourcis clavier du terminal REPL

REPL (Read Evaluate Print Loop) est le nom donné à l’invite interactive de MicroPython accessible sur les appareils Pycom. Il permet de lancer des commandes et de tester du code Python.

Voici les raccourcis clavier les plus utiles :

Ctrl-C : interrompt le code actuel en cours d’exécution, pour récupérer l’invite

Ctrl-D : soft reset (pour un Hard reset, bouton noir RST juste à côté de la led RGB du LoPy)

Ctrl-F (ou Ctrl-Alt-F) : effectue un « safe-boot » du périphérique sans relancer boot.py et main.py

Tab : auto-complétion

Vous pouvez les retrouver en cliquant sur l’onglet Extensions puis Pymakr > Details.

Si vous n’avez plus accès à l’invite de commandes REPL >>> parce que votre code a planté la carte, vous pouvez tout d’abord essayer le safe boot (en étant bien dans la fenêtre d’invite de commande) ctrl+F (sur Atom)  (ou ctrl+alt+F sur VSC), puis  vous pouvez ré-initialiser la mémoire flash [5] :

>>> import os
>>> os.fsformat('/flash')

L’appui du le bouton reset de la LoPy ré-initialise la carte mais relance le code chargé sur la mémoire flash !

Pour aller plus loin dans l’utilisation de la Lopy4 et de la couche PHY LoRa

consultez l’article https://telefab.fr/2021/10/04/aller-plus-loin-avec-la-lopy4/

Références bibliographiques

[1]https://docs.pycom.io/tutorials/basic/rgbled/

[2] https://docs.pycom.io/tutorials/networks/lora/lora-mac/

[3] https://docs.pycom.io/tutorials/networks/lora/module-module/

[4] https://docs.pycom.io/firmwareapi/pycom/network/lora/

[5] https://docs.pycom.io/gettingstarted/programming/safeboot/


											

Robot IA

Envoyé par le 10 Juin 2021 dans À la une, Blog, Portfolio | 0 commentaire

Robot IA – Synthèse du projet CodeV

I – Contexte/Projet/Equipe

 

Dans un monde où la robotique et l’intelligence artificielle sont en plein essor, il est intéressant et nécessaire d’envisager des projets de petite envergure afin d’acquérir les bases de ce domaine, tels que le machine learning. Ce projet consistant à équiper un petit robot motorisé (plateforme JetBot) d’une caméra et lui implanter un code lui permettant de mémoriser et parcourir différents circuits adaptés est alors parfait pour commencer son chemin dans le monde de la robotique et de l’implémentation robotique.

 

Les objectifs du projets sont donc essentiellement de prototyper à taille réduite ce qui pourra par la suite être adapté à taille réelle en voiture autonome, avec un robot capable de se déplacer d’un point A à un point B de manière totalement autonome, tout en analysant son environnement (les panneaux, le marquage au sol…).

 

L’équipe sur le projet est composée de 4 étudiants de FISE A1 : Arthur Didier, Aymen Kallala, Violette Castells et Marianne Bellery. Celle-ci a été guidée et encadrée par Sylvie Kerouedan et Nicolas Farrugia.

 

II – Réalisation

  • Environnement

La création de l’environnement est passée par la conception et l’impression de panneaux. Les visuels ont tous été créés sur PhotoShop dans un style se rapprochant au maximum des panneaux de circulation réels à l’échelle du robot. Ils ont ensuite été imprimés sur du papier collant par les encadrants FabLab. La structure des panneaux a quant à elle été produite sur Tinkercad puis imprimée grâce aux imprimantes 3D du FabLab.

En parallèle le besoin d’avoir une route modulable étant évident, celle-ci à été conçue selon un système de pièces de puzzle. De même les visuels ont été réalisés sur PhotoShop de manière à évoquer clairement une route aux utilisateurs, puis imprimés par le FabLab sur des papiers épais selon un format 50cmx50cm.

 

  • Code

Le code s’est divisé en deux parties distinctes : l’implémentation du suivi de la route et l’implémentation de la reconnaissance des obstacles et limitations. La première permettant au robot d’avancer sur la route en limitant le franchissement des lignes continues blanches. La seconde faisant en sorte que le robot reconnaisse son environnement et agisse en fonction des objets qu’il rencontre. Les types d’objets étant également en deux sous catégories : les obstacles et les panneaux de circulation.

L’implémentation du code est également passée par la collecte de données.

Quant aux obstacle l’architecture de décision finale est la suivante :

 

 

  • Validation

Afin de valider les avancées du projet une liste de tests a été réalisée. Les résultats de celle-ci sont présentés dans le tableau ci-dessous :

III – Composants de l’ensemble environnement + robot

Pour le robot :

Le robot se basera sur la plate-forme Jetbot développée par Nvidia. Avec notamment comme composants ceux du kit JetBot Nano et une batterie.

Pour les pièces puzzles la structure générale est la suivante :

 

IV – Protocole d’utilisation et scénario

Scénario :

L’utilisateur souhaite que le robot se déplace d’un point A à un point B suivant une route avec des contraintes (marquage au sol, panneaux de signalisation…) appelé ici environnement.

  • L’utilisateur pose le robot au sol dans cet environnement au point A. L’utilisateur allume ensuite le robot qui devra alors parcourir le circuit de manière autonome.
  • Si le robot arrive dans une impasse il devra soit faire demi-tour s’il constate un espace suffisant pour l’effectuer ou reculer jusqu’à l’intersection précédente dont le choix a mené à l’impasse afin de prendre une nouvelle route.
  • Lorsque le robot rencontrera un obstacle, si l’espace est suffisant pour passer alors le robot contournera l’obstacle en laissant une distance minimale d’1 cm entre lui et l’obstacle. Si l’espace restant est trop petit alors le robot devra soit faire demi-tour soit reculer jusqu’à l’ancienne intersection comme expliqué précédemment dans le cas de l’impasse.
  • Lorsque le robot arrive au niveau d’un passage piéton il adoptera une vitesse d’avance réduite.
  • Lorsqu’un piéton est sur le passage alors le robot devra s’arrêter à au moins 1 cm du passage piéton.
  • Lorsque le robot rencontre un des 4 panneaux obligatoires, il suivra l’indication.
  • Si un bug de reconnaissance d’obstacle ou de prise de décision par le robot est constaté par l’utilisateur, celui-ci doit l’arrêter et le repositionner 10 cm en amont sur le circuit. Puis il indique par la procédure qui sera développée et donnée dans le mode d’emploi, qu’il y a une erreur afin que l’algorithme d’apprentissage puisse le prendre en compte.
  • Une fois arrivé au point B, le robot s’arrête et l’utilisateur éteint le robot.

 

 

V – Perspectives et pistes d’amélioration

Finalement, ce projet est voué à être transmis et amélioré par de futures équipes. Nous avons effectivement fait en sorte de rentre le code le plus clair possible avec une architecture intuitive pour les différentes parties.

Pour poursuivre ce projet, il faudrait mettre en commun l’ensemble du code (suivi de route et détection des objets), pour que le robot soit capable, sur un circuit complet, à la fois d’éviter les obstacles, de reconnaitre les panneaux et suivre la route. En effet, il est capable de tout faire mais chaque code fonctionne séparément des autres. Cela devra aussi être accompagné d’une amélioration de certains algorithmes afin de garantir un comportement plus robuste et plus juste dans les différents cas d’utilisation.

De plus, on pourrait tenter de remplir les fonctions complémentaires que nous avions évoquées dans le cahier des charges. En particulier, les fonctions liées à l’esthétique du robot, au bruitage ainsi qu’au rajout d’options secondaires vis-à-vis de la circulation du robot sur une route. On pourrait aussi rajouter dans la base de données de nouveaux obstacles et panneaux. Par exemple, on pourrait imaginer rajouter dans la base de données des bonhommes, de différentes tailles et formes modélisant les piétons. On pourrait aussi créer de nouveaux types de panneaux de circulation.

Enfin, il serait aussi intéressant d’améliorer les performances du robot, par exemple, son autonomie ou encore la puissance de ses moteurs.

Objet permettant la visualisation de l’état mer / météo

Envoyé par le 9 Juin 2021 dans À la une, Portfolio, Projets | 0 commentaire

Nous sommes quatre étudiants en FISE A1 d’IMT Atlantique, et nous avons eu comme projet CODEV de réaliser un dispositif permettant de visualiser l’état de la mer et de la météo, au niveau de la plage du Mengam.

Pour cela, nous avons conçu une boîte qui retranscrit de manière imagée et facilement compréhensible les données météorologiques. Le boîte en bois est composée de quatre modules principaux. 

Le premier représente un drapeau qui traduit, par son orientation, la direction du vent, et par son dressage, l’intensité du vent. Pour ce faire, nous avons utilisé des moteurs pas-à-pas ainsi que du matériel fourni par le Téléfab. 

Le deuxième module modélise l’intensité de la houle grâce à un dispositif de 3 niveaux de vagues qui sont éclairées en bleu en fonction de la hauteur réelle de houle. Afin d’imprimer les vagues, nous avons utilisé le logiciel Core-idraw qui est directement lié à la découpe laser du Téléfab. Cette dernière nous a aussi servi à découper dans des planches de peuplier notre boite avec tous les détails souhaités. 

Le troisième module indique s’il fait beau ou s’il pleut, à l’aide d’un soleil et de gouttes de pluie rétro éclairés. Le Téléfab nous a à nouveau fourni les néo pixels et les cartes arduino nécessaires.

Enfin, le quatrième permet d’interpréter toutes les données récupérées depuis internet pour indiquer si l’on peut pratiquer, ou non, un sport nautique (voile, surf ou paddle).

 

Ce projet a été très enrichissant pour nous tous. D’une part, il nous a permis de travailler en groupe pour un client, et par conséquent de découvrir les notions de cahier des charges, de planning et de timing à respecter. D’autre part, nous avons appris à manipuler le matériel du TéléFab (imprimante laser, cartes arduino etc.) ce qui nous resservira pour des projets futurs.

Cyprien, William, Aurélien et Alexandra

 

Réalisation d’une Puzzle Box

Envoyé par le 9 Juin 2021 dans À la une, Portfolio, Projets | 0 commentaire

Alors que nous sommes de plus en plus amenés à nous occuper en intérieur, surtout ces derniers temps au vu du contexte sanitaire, les jeux de réflexion sont un excellent moyen de se divertir en intérieur en occupant son esprit. En tant qu’étudiants ingénieurs en première année de IMT Atlantique, nous voulions mettre à profit nos connaissances en mettant au point un projet de jeu d’énigme interactif et innovant, comportant une part d’électronique.

Dans le cadre de l’UE CODEV 2021 notre équipe de 4 étudiants FISE A1 à IMT Atlantique a  proposé son propre projet (Projet 53) consistant en la réalisation d’une Puzzle Box.

Photo de la puzzle box rendu final 1

Photo de la puzzle box rendu final 1

Photo de la puzzle box rendu final 2

Photo de la puzzle box rendu final 2

Une puzzle box est un jeu qui vient sous la forme d’une boîte qu’il convient d’ouvrir en résolvant différentes énigmes ou casses-têtes, la plupart du temps mécaniques.
Le projet de puzzle box présenté ici consiste en la réalisation d’une boîte à énigme s’adressant à un public d’étudiants scientifiques. La puzzle box réalisée comporte une particularité qui fait son originalité par rapport aux autres puzzle box du marché : elle comporte une partie électronique.

Les objectifs de notre projet étaient triple :

-Réaliser une puzzle box
-Intégrer à la puzzle box une partie électronique, ce qui permet notamment une certaine modulation de celle ci et lui insuffle son originalité
-Adapter notre puzzle box à un public cible (les étudiants de IMT Atlantique) afin de les divertir au mieux

L’intégralité de la réalisation de notre projet a eu lieu dans l’enceinte du FabLab de IMT Atlantique à Brest.

Nous avons dans un premier temps sélectionné les énigmes que nous souhaitions réaliser. Puis la boîte a été modélisée en 3D pour résoudre les problèmes d’incorporations et d’espace entre les énigmes avant de passer à la réalisation pratique avec les outils à notre disposition au FabLab.

Photo de la puzzle box avant l'assemblage de ses composants

Photo de la puzzle box avant l’assemblage de ses composants

Photo de l'intérieur de la puzzle box

Photo de l’intérieur de la puzzle box

La boîte a, tout au long de son processus de conception, fait l’objet de tests poussés, par les membres du projet ainsi que des personnes extérieures, afin de tester chaque ajout.

Finalement, la boîte comporte un jeu de mémoire interactif basé sur des boutons lumineux et sonores, un tiroir aimanté dissimulé, et un tiroir à débloquer par action mécanique.
Des indices sont disséminés à chaque étape de la résolution de la boîte. Ils permettent, une fois rassemblés, de résoudre l’ultime énigme permettant l’ouverture de la boîte qui laisse découvrir la récompense qu’elle contient….

La puzzle box ouverte et sa récompense

La puzzle box ouverte et sa récompense

COSTE Paul, FOUREST Lucas, GOSSE Aurélien, LOYER Baptiste

Fabrication du Kit Archilab

Envoyé par le 21 Jan 2021 dans À la une, Projets | 0 commentaire

Grâce à l’article détaillé du LabFab pour créer son propre kit Archilab, nous avons réalisé pour le centre d’Appui et de Ressources pour l’Apprentissage et l’Enseignement (CARÆ) d’IMT Atlantique deux jeux complets d‘Archilab, un outil pour réfléchir et co-construire des espaces.

La boîte de jeu n’ayant pas été encore conçue j’ai pu en créer une grâce à l’outil de conception de boîtes très complet: Boxes.py. La boîte a été faite en medium 6mm, mais le plus simple est d’adapter votre modèle en fonction de l’épaisseur de bois utilisée. Voici les paramètres utilisés, il suffit de cliquer sur le lien, puis cliquer sur « Générer » et d’enregistrer sous le fichier .stl qui s’affiche.

 

RéCup – Solution technique

Envoyé par le 11 Jan 2021 dans TAF CoOC | 0 commentaire

This entry is part 6 of 6 in the series RéCup

Solution technique – RéCup

Arthur PILETTE – Vincent GUILLON – Raphael VOYER – Pierre DUGAST

I. Présentation

A. Objectifs

B. Design

II. Conception technique 

A. Structure physique (mécanique + matériel utilisé)

  • Matériel utilisé
  • Structure mécanique du système
  • Circuit électrique

B. Structure logicielle

  • Présentation des différents programmes
  • Diagrammes de séquence
  • Logigrammes (interactions entre les programmes et lien vers le code)

C. Interactions avec le système

  • Fonctionnalités
  • Diagrammes de cas d’utilisation

III. Choix de conception

A. Caution

B. Structure mécanique

C. Analyse de tasses (détection + présence)

IV. Améliorations possibles du système

A. Esthétisme (site Web avec CSS + design physique)

B. Mise en place d’une application Android

C. Amélioration des performances

 

I. Présentation

A. Introduction de la solution et de ses objectifs

Les cafés, restaurants et cafétérias font face depuis de nombreuses années à des vols et casses de tasses. Bien que la tasse ne soit pas un objet de valeur, à grande échelle ces actes ont de multiples conséquences. Le premier est l’impact financier. Ce sont plus de 100 tasses qui sont perdues chaque année. Le coup de rachat étant d’environ 1€20 par unité en moyenne pour les grandes et petites tasses. L’organisation a un coût minimum de 120€ chaque année pour remplacer ses tasses. Le second est l’impact environnemental. Étant donné qu’il est nécessaire d’utiliser un nouveau matériel sans que le précédent ait complété son cycle de vie, on perd l’avantage de l’impact écologique de la tasse en céramique sur ses concurrents. Il est donc nécessaire de prolonger la vie de la tasse pour améliorer le bilan environnemental des cafés, restaurants et cafétérias.

C’est pourquoi nous avons mis au point la solution RéCup afin de réduire les pertes de tasses de la cafétéria de l’IMT Atlantique. Le système réCup vise donc à répondre aux défis suivants :

  • Réduire l’impact financier liés aux pertes de tasses pour la cafétéria
  • Réduire l’impact environnemental induit par les contenants de boissons chaudes
  • Inciter les consommateurs à rendre leurs tasses

B. Design

Le design de notre système est assez simple car une grande partie du système est protégée par l’armature de notre système. Seuls les composants dont l’interaction est utile dans la réalisation d’une ou plusieurs opérations sont visibles depuis l’extérieur du système. Parmi ces éléments on retrouve l’afficheur LCD permettant d’indiquer à l’utilisateur l’avancement des opérations et les tâches à suivre, le module RFID lui permettant de s’identifier ainsi que le compartiment de dépôt de tasse. En définitive, le design final de notre prototype est le suivant :

II. Conception technique 

Le système réalisant nos divers services est relativement complexe car il intègre à la fois une partie mécanique, électronique et logicielle. Afin que vous puissiez comprendre le fonctionnement technique et la structure de ce système, nous en avons détaillé la conception technique.

A. Structure physique (mécanique + matériel utilisé)

  1. Matériel utilisé

Avant de vous présenter les différents points de la conception technique, il est important de vous présenter le matériel utilisé. La liste de matériel que nous avons établie vous permettra de mieux comprendre le rôle de chacun des composants et leur contribution dans le système global. Ce tableau comprend aussi une analyse du coût d’achat des différents composants et ainsi vous présenter le budget total nécessaire afin de mettre en place une telle solution.

 

MATÉRIEL PRIX
Raspberry Pi 3B+ 40€
Pi camera module V2 15€
Ecran LCD I2C 10€
Détecteur de présence 4€
Boutons poussoirs 1€
Led couleurs x5 

+ LED éclairage x3

2€
Module RFID + badge RFID 2€
Arduino 15€
CNC shield et drivers moteurs 6€
Axes aluminium 26€
Poulies 11€
Alimentation 12V 5A 9,3€
Visserie 13€
Moteurs pas à pas type NEMA 17  x3 21€
Roues  5,5€
Courroies  3,5€
Servomoteurs x2 2,5€
Interrupteurs fin de course x7 3€
Filament PETG environ 400 gr 12€
Bois  récup

 

Raspberry Pi 3B+

Le Raspberry Pi est un nano-ordinateur capable disposant de GPIO afin de piloter un grand nombre de composants. Nous avons opté pour le Raspberry Pi afin de piloter l’ensemble des composants du projet car le nombre de GPIO d’une carte Arduino UNO ou AT MEGA n’est pas suffisant pour brancher l’ensemble de nos composants. De plus, notre logique séquentielle implique d’utiliser plusieurs composants simultanément tels que le bouton Terminer et le capteur ultrason pour permettre à l’utilisateur de terminer son opération de dépôt ou déposer une autre tasse. Un Arduino n’est pas capable de réaliser de telles opérations alors que le Raspberry capable de gérer des processus peut utiliser les “Threads” à cet effet pour paralléliser certaines parties de notre code. Pour finir, le Raspberry dispose aussi de ressources suffisantes (RAM, CPU, …) pour accepter un module léger de deep learning qui nous sera utile pour l’analyse d’objets.

Arduino et CNC shield

En complément de notre Raspberry Pi, nous avons utilisé un Arduino afin de lui confier la tâche de gestion du système de stockage. Cela permet permet trois choses ;  tout d’abord l’utilisation d’un shield CNC qui permet d’accueillir les drivers moteurs, l’arrivée du courant de puissance pour les moteurs, les connecteurs pour les capteurs de fin de course, etc. L’utilisation de ce shield simplifie et organise grandement le câblage. De plus l’arduino est ensuite relié au Raspberry via un câble USB, ce qui est nécessaire. Brancher tout le système de stockage sur le Raspberry aurait occupé une vingtaine de pins (soit la moitié du GPIO), ne laissant alors qu’une dizaine de pins data pour le reste des composants de notre solution, ce qui n’aurait pas suffit. Finalement cette architecture permet d’utiliser le logiciel GRBL sur l’arduino, qui permet de faciliter la gestion des déplacements du système de stockage.

Ecran LCD I2C

L’écran LCD a aussi un rôle fondamental dans notre système car il joue le rôle de front-end avec notre système en affichant les informations à l’écran. Cet écran peut afficher des instructions telles que :

  • Présenter votre badge
  • Déposer la tasse
  • Retirer l’objet

L’écran indiquera aussi les résultats des opérations réalisées par notre système tels que : 

  • Caution rendue
  • L’objet déposé est une tasse

Module RFID et badge

Le module RFID est un module de radio-identification permettant la mémorisation et la récupération de données à distance. Ce module est capable de reconnaître les tags présents dans les différents badges. Ainsi le module RFID nous permet d’identifier de manière unique chacun des utilisateurs évitant ainsi d’éventuels vols liés à des usurpations d’identité.

Capteur ultrason 

Le capteur ultrason permet de détecter des éléments présents en champ proche grâce à la réverbération des ondes qu’il émet. Ce composant permet ainsi de détecter lorsqu’un objet est déposé dans le compartiment. Un tel mode de fonctionnement permet de n’utiliser la caméra utilisée pour l’analyse que lorsqu’un objet est détecté. De ce fait, la consommation en ressource et en énergie est bien plus modérée améliorant ainsi la durabilité de notre système. 

Module Pi-Caméra

Le module Pi Caméra est un module de caméra adapté pour le Raspberry Pi nous permettant de visionner l’objet qui a été déposé dans le compartiment pour que le Raspberry Pi l’analyse. Bien que ce module soit plus intéressant qu’une Webcam car il est plus petit et est plus adapté au Raspberry Pi, il est tout de même possible d’utiliser une webcam pour réaliser cette fonction.

LED éclairage

Les LED d’éclairage permettent d’illuminer le compartiment de dépôt afin que l’objet soit visible par la caméra pour l’analyse. 

Bouton poussoir “Terminer”

Ce bouton permet de réaliser de mettre en place un mécanisme d’interrupteur permettant d’indiquer au système lorsque l’utilisateur souhaite terminer l’opération de dépôt.

Distribution (Axes aluminium, roues, chariot)

Le système de distribution comprend différents éléments tels que des axes, des roues et un chariot permettant d’acheminer la tasse jusqu’aux bacs de stockage. Les axes sont des profilés 2040. Grâce à des écrous adaptés (T-nuts) qui se glissent dans la gorge des profilés, on peut facilement assembler ces axes sans les percer mais également y monter des pièces (supports moteurs, …). Le tout offre une structure solide.

Ces profilés permettent aussi de guider les roues qui permettent la mobilité du chariot transportant les tasses sur l’axe vertical et l’axe horizontal.

Moteurs pas à pas, poulies, courroies 

Les deux axes du système sont entraînés par des moteurs pas à pas de type Nema 17, de type 200 pas par révolution, avec un couple de 3.2 kg-cm. Deux moteurs fonctionnant de manière synchronisée motorisent l’axe vertical, car ceux-ci doivent supporter le poids de l’axe horizontal. Ce dernier est motorisé par un seul moteur, vu qu’il ne doit faire bouger que le chariot contenant la tasse à stocker. Les deux axes (vertical et horizontal) sont entraînés par courroie et sont guidés par des roues sur roulement, permettant un fonctionnement rapide et fluide.

Servomoteurs 

Deux servomoteurs sont utilisés pour la même fonction, mais à deux endroits différents. Ils permettent de retenir la tasse dans le compartiment d’analyse de la tasse et sur le chariot mobile qui distribue les tasses. Grâce à un système de bielle, ils contrôlent la fermeture et l’ouverture de la porte qui retient ou libère la tasse.

position fermée                                                 position ouverte

Alimentation 12V 5A

Elle permet de fournir la puissance nécessaire au bon fonctionnement des moteurs pas à pas.

Interrupteur à lame souple

Ces contacteurs servent à différentes fonctions dans la solution. Deux sont utilisés comme interrupteur de fin de course au sein du système de stockage, permettant de calibrer le système précisément au démarrage. 

Les autres servent de garde-fou. Un premier permet d’arrêter le système si la porte arrière (accès aux casiers) est ouverte. Trois autres détectent la présence des trois casiers de stockage. Si l’un d’eux manque,  la machine est également bloquée. Un autre permet de savoir si le chariot qui transporte les tasses est à sa position initiale, prêt à recevoir une tasse. Si ce n’est pas le cas, on demande au système de stockage de se replacer correctement.

Un dernier contacteur permet de savoir si la tasse déposée est grande ou petite pour la ranger dans un casier approprié.

Filament PETG

Il a permis de réaliser une grande partie des pièces mécaniques du système : liaison des axes, supports moteurs, chariot, … Toutes les pièces bleues sont réalisées en impression 3D. Ce filament s’imprime assez facilement et offre une meilleure tenue mécanique par rapport au PLA.

Bois

Du médium de 3 et 6 mm a permis de construire différents éléments du système par découpe laser : casiers, façade avant, etc. Des planches de pin de 18mm ont été nécessaires pour fixer les casiers, créer une porte et offrir une structure sur laquelle a été assemblé tout le système. 

  1. Structure mécanique du système

  1. Circuit électronique

L’ensemble des composants nécessaires au fonctionnement du système doivent chacun être branché de manière en fonction de leur mécanique interne. Nous avons donc établi le schéma de câblage global permettant le fonctionnement des composants et donc du système. Pour des raisons de lisibilité, les pin et GPIO utilisés dans notre code sont différents du schéma.

Schéma électronique lié à la Raspberry

Schéma électronique lié à l’arduino

B. Structure logicielle

Bien que notre système soit fortement basé sur des actions mécaniques et physiques celles-ci sont ordonnancées par une structure logicielle relativement importante.

  1. Base de données

 

La base de données est le système backend principal de notre système. Il permet de stocker les informations générales des comptes utilisateurs (collaborateurs et utilisateurs). Le contenu de la base de données est présent dans la capture d’écran ci-dessous :

Ces informations sont récupérées au besoin via des requêtes SQL transmises par les programmes PHP du système. On répertorie actuellement deux cas de figure nécessitant la collecte de ces informations : 

  • Lors de l’authentification d’un utilisateur au niveau du site Web car il est nécessaire de vérifier que l’identifiant et le mot de passe correspondent à ceux de l’utilisateur. Ainsi cela permet d’augmenter la sécurité du système car  seuls les utilisateurs autorisés peuvent profiter des services du système. 
  • Lors des identifications par badge réalisées afin d’emprunter ou déposer une tasse. En effet, il est nécessaire de récupérer les informations de l’utilisateur afin de modifier son nombre de tasses empruntées et son solde en conséquence.

        2.Architecture logicielle

L’architecture logicielle de notre système repose sur des programmes réalisés en différents langages de programmation. 

Programmes PHP liés au site Web 

Notre site Web nécessite de réaliser des opérations calculatoires ainsi que des requêtes, il est donc nécessaire de le mettre en place à l’aide de programmes PHP. Comme vous pouvez le voir sur l’architecture logicielle, le code lié au site Web est présent dans le répertoire appelé “HTML”. Ce dernier est composé des éléments suivants : 

 

NOM DU PROGRAMME DESCRIPTION
html/utilisateur/index.php Affiche les informations de l’utilisateur (nombre de tasses empruntées, caution et solde) s’il est authentifié sinon il est redirigé vers la page html/utilisateur/login.php
html/utilisateur/login.php Affiche la page d’authentification de l’utilisateur
html/utilisateur/logout.php Affiche la page de déconnexion de l’utilisateur
html/utilisateur/config.php Permet la connexion à la base de données 
html/collaborateur/index.php Affiche les informations de gestion des tasses (nombre de tasses total empruntées, utilisateur n’ayant pas rendu leur tasse) si le collaborateur est authentifié sinon il est redirigé vers la page html/collaborateur/login.php
html/collaborateur/login.php Affiche la page d’authentification du collaborateur
html/collaborateur/logout.php Affiche la page de déconnexion du collaborateur
html/collaborateur/config.php Permet la connexion à la base de données 

 

Programmes Python liés au fonctionnement du système

Les différentes actions garantissant le  fonctionnement général de notre système comprenant le dépôt de tasse, la gestion de la caution, la distribution des tasses dans les bacs de stockage etc. ont été établies grâce à plusieurs programmes python. Chacun de ces programmes Python interagissent avec un composant spécifique du système afin de conserver une bonne granularité de gestion du système et obtenir un programme global intelligible pour un futur lecteur. L’ensemble de ces programmes Python sont décrits dans le tableau ci-dessous.

NOM DU PROGRAMME DESCRIPTION
main.py Programme python réalisant le séquencement logique du système. Ce programme appelle pour cela les fonctions des autres programmes au besoin.
afficheur.py Programme permettant de piloter l’écran LCD afin de réaliser divers affichage selon les différentes situations (bonjour, badge invalide etc.)
bac_ouvert.py Programme interagissant avec un interrupteur qui vérifie que la porte permettant la récupération des bacs de stockage est fermée. Lorsque la porte est ouverte, le fonctionnement du système lié au dépôt de tasse se met en pause jusqu’à la porte soit refermée.
bouton_terminer.py Programme interagissant avec le bouton poussoir permettant de terminer une opération de dépôt de tasse. Si ce bouton poussoir est pressé suite au dépôt d’une tasse alors l’opération de dépôt se termine.
casier.py Défini un objet casier comportant différents attributs. Pour chaque casier, on connaît le nombre de tasses dans chaque colonne.
depose.py Ce programme sert d’intermédiaire entre les programmes stockage.py et machine.py. Il convertit les ordres du programme stockage.py (ex. :stocker une tasse dans le casier 1, en colonne 2) en coordonnés utilisés par le programme machine.py. 
detection_tasse.py Programme interagissant avec la caméra afin de l’activer si un objet est détecté dans le compartiment de dépôt (presence_tasse.py) et d’appeler les fonctions d’analyse d’objet (TFLite_detection_image_reCup.py).
i2c_lib.py, lcd_py Programmes appelés par le programme afficheur.py afin de permettre le fonctionnement de l’écran I2C. Ces programmes contiennent des librairies ainsi que des fonctions d’affichage intrinsèques au matériel.
liberation_tasse.py Programme interagissant avec le servomoteur bloquant le passage de la tasse vers le chariot mobile. Si une tasse est détectée dans le compartiment, la fonction de déblocage du servomoteur de ce programme est appelée.
machine.py  Ce programme permet de communiquer en série avec le programme GRBL qui tourne sur l’arduino. Il permet d’envoyer des commandes pour initialiser le système de stockage ou déplacer le chariot vers une position particulière.
presence_plateau.py Programme interagissant avec les interrupteurs détectant la présence des différents casiers. Pour que le système fonctionne correctement, il est nécessaire que l’ensemble des interrupteurs soient pressés. Sinon le programme général (main) se met en attente.
presence_plateau_distri.py Ce programme permet de savoir si le chariot du système de stockage est prêt à recevoir une tasse. Il vérifie l’état d’un interrupteur à lamelle. Si le chariot n’est pas au bon endroit, il demande au système de stockage de le replacer.
presence_tasse.py Programme interagissant avec le capteur ultrason afin de détecter la présence d’un objet déposé dans le compartiment de dépôt.
requete_sql.py Programme réalisant les requêtes SQL nécessaires à la gestion des cautions des utilisateurs inscrits dans la base de données.
rfid.py Programme interagissant avec le module RFID afin de récupérer l’ID du badge qui lui est présenté. 
stockage.py Ce programme permet de lancer le stockage d’une tasse qui a été déposée et validée. Suivant la taille de la tasse et la place restante dans les différents casiers, il va choisir le bon endroit où déposer la tasse
tasse.py Définir un objet tasse. Il comporte un attribut qui permet de savoir si la tasse est grande ou petite.
TFLite_detection_image_reCup.py Programme interagissant avec l’outil de deep learning Tensorflow Lite afin d’analyser la photo de l’objet déposé dans le compartiment de dépôt prise par la caméra.
TFLite_detection_video.py, TFLite_detection_webcam.py Autres programmes d’analyse d’éléments dans le cadre de vidéos, de stream ou de webcam. Ces programmes ne sont pas appelés dans notre programme principal mais peuvent servir pour d’autres applications du système.

3.Diagrammes de séquence

Lorsque l’utilisateur interagit avec le système, il appelle des fonctions de programmes réalisant les services attendus. Ces fonctions peuvent elles-mêmes appeler d’autres fonctions d’autres programmes de l’arborescence pour leur propre fonctionnement et ainsi pouvoir réaliser la séquence d’actions attendue. Il est donc nécessaire de décrire les différents appels de fonctions permettant de réaliser la suite d’action attendue afin qu’un néophyte puisse comprendre la mécanique logicielle interne du système. Nous avons pour cela mis en place plusieurs diagrammes de séquence décrivant les scénarii possibles.

Diagramme de séquence indiquant l’utilisation d’un badge invalide pour l’identification

Diagramme de séquence indiquant un processus complet de dépôt d’une tasse


4. Logigrammes (avec interaction entre les programmes)

 

 

Avant toute réalisation technique, nous avons défini le chemin logique que notre système doit suivre pour réaliser nos différents services et éviter des scénarios d’erreurs non traités. L’ensemble des programmes ont été établis selon cette logique décisionnelle représentée dans les schémas suivants.

Logigramme du fonctionnement du système :

 Logigramme du programme PHP :

5. Logique de stockage

Le système RéCup est pensé pour stocker un grand nombre de tasses. Il accepte les deux formats de tasse existants à la cafétéria de l’IMT Atlantique, les grandes et les petites. Il peut stocker jusqu’à 36 petites tasses et 30 grandes tasses.

Pour ce faire, chaque casier est compartimenté en 4 colonnes ; deux pouvant accueillir chacune 6 petites tasses (p1 et p2), et deux autres pouvant accueillir chacune 5 grandes tasses(g1 et g2).

Le système comporte trois casiers identiques. 

Il range alors les tasses en commençant par le premier casier au plus bas (si celui-ci n’est pas plein, auquel cas le programme monte la tasse au deuxième. Il remplit toujours les casiers de la même manière ; il commence par stocker en “p1” si la tasse est petite. Lorsque “p1” est plein, il passe à “p2”. Si “p2” est plein, il passe au “p1” du casier suivant. Le fonctionnement est identique pour les grandes tasses, en utilisant les emplacements “g1” et “g2”.

 

organisation d’un casier

 

C. Interactions avec le système

  1. Fonctionnalités et mise en situation

Le système RéCup réalise un grand nombre de fonctionnalités visant à automatiser la gestion des emprunts et dépôts de tasse. Nous avons défini dans cette partie les fonctionnalités majeures de notre système incluant une mise en situation afin de mieux discerner les différentes interactions avec le système.

Prélèvement d’une caution lors de l’emprunt d’une tasse

L’une des fonctionnalités principales de notre système RéCup est le mécanisme de caution visant à inciter les consommateurs à ramener leur tasse. Ce prélèvement est réalisé de manière transparente lors de la commande de boisson chaude réalisée par les collaborateurs. Pour cela, l’utilisateur s’identifie en présentant son badge au niveau du lecteur RFID afin de pouvoir effectuer une requête vers la base de données pour récupérer les données de l’utilisateur. Suite à ça, le collaborateur indique sur sa machine la boisson commandée par l’utilisateur, ce qui déclenche une seconde requête vers la base de données. Cette dernière a pour but de modifier le nombre de tasses empruntées pour l’utilisateur identifié.

Le schéma fonctionnel décrivant la situation est le suivant : 

Déposer une tasse

Le système RéCup fournit aussi la possibilité aux utilisateurs de pouvoir déposer leur tasse dans un système de collecte sans l’intervention d’un collaborateur de la cafétéria. Pour ceci, l’utilisateur s’identifie en présentant son badge au niveau du lecteur RFID permettant ainsi d’effectuer une requête vers la BDD permettant de récupérer les informations du compte de l’utilisateur. L’utilisateur peut à présent déposer l’objet à l’intérieur du compartiment de stockage afin que le système puisse l’analyser: Si l’objet détecté est une tasse alors le système s’occupe de la distribution de la tasse vers les bacs de stockage. L’utilisateur peut alors simultanément disposer une nouvelle tasse ou terminer son opération de dépôt. Dans ce second cas, une dernière requête sera faite vers la base de données afin de supprimer la caution et créditer le solde de l’utilisateur.

Consultation des informations de l’utilisateur depuis le site Web

Un utilisateur peut consulter les informations relatives à ses emprunts de tasse depuis le site Web prévu à cet effet. L’utilisateur renseigne pour ceci l’URL du système http://192.168.1.98 afin d’être redirigé vers la page d’accueil et choisir son mode de connexion : collaborateur ou utilisateur.

Dans les deux cas l’utilisateur devra au préalable s’authentifier auprès du système en renseignant son identifiant et son mot de passe. Ces derniers seront envoyés via une requête vers la BDD permettant ainsi de vérifier si l’utilisateur appartient bien au groupe d’utilisateur ou collaborateur.

Une fois authentifié, l’utilisateur peut alors consulter les informations présentes sur la page web de son compte.

Une fois authentifié, le collaborateur peut alors consulter les informations présentes sur la page web liée à son profil.

2.Diagrammes de cas d’utilisation

Selon le rôle des acteurs interagissant avec le système nous pouvons répertorier plusieurs use-cases. Ceux qui ont été mis en place ont été représentés dans les diagrammes de use-case ci-dessous : 

Utilisateur : 

 

Collaborateur : 

III. Choix de conception

A. Caution et avantages participatifs

Le système visant à inciter les utilisateurs à rendre leur tasse a été complexe à mettre en place car il doit respecter un grand nombre de contraintes : 

  • Être abordable financièrement pour les utilisateurs
  • Ne pas créer des flux d’argents illicites
  • Ne pas être éthiquement répréhensible
  • Engager les utilisateurs à rendre leur tasse intuitivement

Plusieurs solutions ont été pensées pour répondre à ce besoin. Tout d’abord, nous avions pensé à un système de caution qui ponctionne aux utilisateurs une petite somme permettant ainsi de rembourser automatiquement l’organisme qui prête les tasses en cas de casse, perte ou vol. 

Dans la première version de ce système nous avions estimé que la possibilité de récupérer la caution des utilisateurs qui abandonnent leur tasses pourrait être intéressante afin d’inciter les utilisateurs à ramener leur tasse. Cependant cette possibilité soulève à la fois des problèmes éthiques et juridiques. D’une part, un tel système peut inciter des utilisateurs malveillants à dérober les tasses des autres afin de récupérer les cautions des autres utilisateurs. De plus, un système générant de tels flux financiers entre les utilisateurs est totalement illégal. 

Nous avons donc imaginé un second système basé sur des avantages fournis selon le nombre de tasses rendues. Par exemple, lorsqu’un utilisateur ramène une vingtaine de tasses, la cafétéria lui offre une boisson chaude ou un soda. Cependant, dans le cadre d’une école avec un grand nombre d’élèves qui consomment fréquemment des boissons chaudes, ce type de solution peut s’avérer très onéreux ce qui ne respecte pas la contrainte budgétaire du système.

Nous avons donc finalement opté pour la première option en repensant le système de caution pour qu’il respecte à la fois l’éthique et la loi. Contrairement au système de caution classique, il n’est pas possible de récupérer plus d’argent que la caution qui nous a été prélevée. Nous avons jugé qu’appliquer une caution que l’utilisateur peut perdre s’il ne ramène pas sa tasse serait suffisante pour impliquer les utilisateurs dans le processus de collecte des tasses. Par conséquent, nous avons estimé que cette solution est celle qui répond le mieux au cahier des charges.

B. Structure mécanique

Pour être utilisable ce projet a nécessité une importante phase de conception mécanique. En effet, une fois la tasse analysée et acceptée, il faut la stocker ; c’est le but d’une consigne.

Casiers 

Au début du projet, la manière dont nous allions réaliser ce stockage était notre principal questionnement. Nous voulions stocker un nombre assez important de tasses afin que la consigne ne soit pas trop vite pleine, par exemple lors des pauses, où beaucoup de personnes restituent leur tasse au même moment. Nous savions qu’il nous fallait un système qui permette d’empiler plusieurs couches de tasses, afin d’avoir un maximum de tasses dans un volume donné. Nous avons pensé à différents systèmes ; par exemple un bras robotisé qui pourrait empiler des tasses. Mais cela semblait trop complexe à réaliser. Une autre idée était de faire un tunnel incliné avec des fentes de différentes tailles menant à un casier semblable à ceux réalisés, les tasses seraient tombées aux bons emplacements par gravité. Finalement, nous avons mêlé cette solution à un système actif permettant de déplacer la tasse grâce à un chariot, puis de la laisser tomber dans le casier par gravité. Ainsi nous pouvons empiler trois casiers et stocker un nombre important de tasses. Il est facile pour le personnel de retirer ces casiers en ouvrant la porte arrière puis en les faisant glisser. 

 prototype en carton pour trouver l’angle d’inclinaison                                            rendu 3D des casiers 

 

Système de déplacement de la tasse

Comme expliqué juste avant, en plus des casiers, il est nécessaire d’avoir un système qui permet d’amener la tasse devant une colonne d’un casier pour ensuite la stocker en la faisant glisser par gravité. 

Pour ce faire, il nous fallait un système permettant un déplacement vertical et horizontal. Nous avons été inspirés par des structures de CNC ou imprimantes 3D. Nous avons conçu un cadre en profilés aluminiums 2040, courant pour des réalisations de CNC ou imprimantes 3D. Il nous fallait un système rapide, nous avons donc préféré un entraînement par courroie plutôt que des vis sans fin, qui auraient été plus lentes. Le choix d’un guidage par roues montées sur roulements est également un système éprouvé, nous l’avons donc retenu pour notre réalisation.

Les moteurs pas à pas retenus sont également très répandus dans le domaine de l’impression 3D/ découpe CNC. En faisant des recherches nous avons pu constater qu’une architecture simple et éprouvée est l’utilisation d’un shield avec les drivers moteurs a4988 sur un Arduino Uno. Le logiciel GRBL installé sur l’arduino permet ensuite de contrôler les moteurs en leur envoyant des commandes standardisées en GCODE.

arduino, cnc shield et drivers moteurs

En dehors des composants assez classiques, nous nécessitions un système sur mesure, au vu de nos besoins spécifiques, qui sont différents d’une CNC ou d’une imprimante 3D. Nous avons entièrement modélisé le système de déplacement en 3D sur un logiciel de CAO. Cette étape était nécessaire car un grand nombre de pièces a ensuite été imprimé en 3D, en PETG pour avoir des pièces suffisamment solides. Le fait de tout réaliser en CAO nous a permis d’identifier de potentiels problèmes (manque d’espace entre deux pièces,…) et de les corriger avant la réalisation. Le temps passé en CAO a été rentabilisé car il a permis un montage sans accrocs.

Modélisation du système de déplacement en CAO

C. Analyse de tasses (détection + présence)

Le système de détection de présence d’objet et de son analyse a aussi été sujet à des choix de conceptions complexes. Il est possible d’utiliser le Raspberry Pi afin qu’il utilise la caméra en permanence pour analyser en temps réel les objets déposés dans le compartiment. Dans un tel cas de figure, les processus d’utilisation de la caméra et d’analyse de l’objet sont constamment actifs. Par conséquent, un grand volume de ressources logicielles sont requis pour cette opération. Si l’on cumule cette utilisation de ressources à celles liées aux actions de distribution des tasses, d’identification et autres, la qualité de service peut être fortement détériorée et le matériel peut être à terme endommagé. Il est donc nécessaire d’optimiser au maximum les ressources utilisées par le système d’analyse de l’objet. Pour cela, une avons envisagé deux solutions qui permettent de grandement limiter l’utilisation des ressources sans détériorer la qualité de service.

Tout d’abord, nous avons utilisé le TensorFlow Lite comme outil d’exécution des modèles de prédiction TensorFlow plutôt que l’outil classique Tensorflow. Tensorflow Lite est plus adapté pour exécuter des modèles de prédiction sur des appareils mobiles et des objets connectés. Les inférences d’apprentissage profond réalisées avec Tensorflow Lite sont plus rapides et occupent une plus faible taille. Bien que les résultats fournis avant un tel outil soient de moins bonne qualité, un objet tel qu’une tasse étant très simple à détecter, les performances d’analyse de l’objet ne seront pas amoindries.

Après avoir étudié les divers programmes de détections d’objet, nous avons réussi à implémenter un code capable de réaliser une détection à partir d’une image à la place d’un flux vidéo en temps réel récupéré par la caméra. Ainsi il sera possible de prendre une photo du compartiment lorsqu’un objet y est déposé afin de l’analyser et donc de limiter grandement les ressources allouées pour l’analyse de l’objet. Cependant, un tel mode de fonctionnement requiert de déterminer lorsqu’un objet a été déposé afin de déclencher la photographie. Pour répondre à ce besoin, nous avons ajouté un système de détection de présence à l’intérieur du compartiment de dépôt. Après avoir réalisé plusieurs tests, nous avons de plus observé que les inférences et donc les scores de détection faites sur une photographie plutôt qu’une vidéo sont de meilleure qualité. 

Grâce à ces deux méthodes nous avons pu réduire significativement les ressources logicielles tout en améliorant les résultats d’analyse de l’objet.

IV. Améliorations possibles du système

Bien que notre système soit à présent opérationnel et qu’il offre les fonctionnalités principales, il peut être grandement amélioré. Ces modifications visent à améliorer les performances de notre système, son accessibilité et son esthétique.

A. Esthétisme et ergonomie (site Web avec CSS + design physique)

L’esthétisme et l’ergonomie sont deux points d’amélioration qui peuvent être importants dans l’optique de produire notre système. En effet, notre système fait appel à la civilité des utilisateurs en leur prélevant une caution pour l’emprunt des tasses. Il est donc très important qu’il soit accepté par la majorité des utilisateurs. Cette acceptation du système passe évidemment par une esthétique travaillée et une bonne ergonomie permettant aux utilisateurs d’utiliser le système intuitivement.

L’esthétisme et l’ergonomie du système passe par une réédition de l’interface web graphique permettant la gestion des tasses pour les utilisateurs et les collaborateurs. Celle-ci n’est pour l’instant basée que sur un code fournissant les fonctionnalités mais ne propose pas d’interface web intuitive pour les utilisateurs. Il sera donc nécessaire de concevoir un menu et une navigation intuitive pour ce site Web. De plus, notre page web n’est pas liée à une fiche CSS. Une autre amélioration serait donc d’implémenter cette fiche CSS pour améliorer l’esthétique du site Web et en organiser les différents éléments qui la composent. 

B. Mise en ligne du système et mise en place d’une application Android

Notre site web n’est actuellement joignable que lorsque l’utilisateur se trouve sur le même réseau IP que notre système. Afin que les utilisateurs puissent accéder à distance à notre service il sera nécessaire d’assigner une adresse IP publique et un nom de domaine à notre système. Lorsque cette IP ou le nom de domaine sont renseignés, les utilisateurs et collaborateurs seront redirigés vers notre site web leur permettant ainsi de réaliser leurs actions ou consulter leurs informations à distance. 

Nous pourrions aussi envisager de créer une application Android qui réaliserait les mêmes fonctionnalités que notre site Web mais qui serait plus adaptée pour l’utilisation des services depuis un smartphone.

C. Amélioration des performances

Actuellement notre système n’a pas été optimisé et les performances sont donc grandement améliorables. Cette optimisation passe tout d’abord par une revue du code utilisé au niveau des différentes boucles et conditions. Pour cela, il nous faudrait déterminer un chemin logique optimal permettant de réduire le nombre d’opérations effectuées tout en conservant les mêmes fonctionnalités. Une optimisation des ressources utilisées par le système de détection de tasse pourrait aussi être réalisée. En effet, ce système nécessite pour l’instant un grand nombre de ressources logicielles pour fonctionner. Une analyse du fonctionnement logiciel de la caméra et des systèmes de prédiction permettrait de mieux comprendre leur fonctionnement et ensuite de limiter le nombre d’opérations nécessaires et donc optimiser les ressources.

La réalisation de l’ensemble de ces points permettrait une amélioration significative de la qualité de service rendue par le produit et nous permettrait d’envisager une mise en production.

D. Sécurité physique de la consigne

Notre système était pensé pour être une boîte fermée, dont l’intérieur est inaccessible aux utilisateurs. Par manque de temps et de matériaux nous n’avons pu totalement satisfaire cette condition. Il faudrait qu’on monte les panneaux latéraux et le panneau supérieur pour garantir ce niveau de sécurité.

D’autre part, les collaborateurs doivent avoir accès aux casiers via la porte arrière de la machine. Également par manque de temps, nous n’avons mis qu’un loquet symbolique pour fermer la porte. Il faudrait qu’on réalise un système de blocage de la porte plus sécurisé, par exemple grâce à un servomoteur.

exemple de verrou actionné par un servomoteur, trouvé sur internet

Le collaborateur pourrait déverrouiller la porte grâce à son badge IMT.

E. Ergonomie pour le collaborateur

Actuellement le collaborateur dispose d’un bouton permettant de réinitialiser le compte de tasse lorsqu’il vide les casiers pleins et les replace dans la machine une fois vidés. Il est placé juste derrière la porte donnant accès aux casiers. Cependant le collaborateur n’a pas de retour visuel lui indiquant que la réinitialisation a été effective ; il est obligé de faire le tour du système pour consulter l’écran destiné aux utilisateurs. On pourrait imaginer simplement une led rouge et une led verte placés à côté du bouton réinitialiser. Lorsque la consigne est pleine, la rouge est allumée ; après appui sur le bouton, la rouge s’éteindra et la verte s’allumera.

Lien github : https://github.com/reCup-CoOC/reCup

Quelques images du prototype

Une vidéo de fonctionnement du prototype

https://drive.google.com/file/d/1Wx0B3tlcaYPh24vZnyMJAy70tkAGq-TC/view?usp=sharing

Hypn – Solution technique

Envoyé par le 8 Jan 2021 dans Projets, TAF CoOC | 0 commentaire

This entry is part 6 of 6 in the series Hypn

Groupe 4 – BOUTHET ELODIE, LEBORGNE ROMEO, SAMMARI AKRAM

 

Solution technique

 

 

Présentation de la solution

 

La solution HYPN est composée d’une borne de rechargement USB munie de tags NFC et d’une application mobile de blocage présente sur le portable de l’enfant. Le but est d’allier une limitation logicielle avec une habitude gestuelle afin de se séparer physiquement de son portable.

Comment ça marche ? L’application inclut un compteur de temps, qui diminue lorsque le portable est en cours d’utilisation. Une fois ce compteur à zéro, l’application bloque une grosse partie des fonctionnalités du portable. Pour le recharger, l’enfant doit déposer son smartphone sur la borne, idéalement positionné dans une des parties communes du lieu de vie. Ce contact avec la borne permet de recharger le temps d’utilisation du portable.

Ainsi, une fois les paramètres de l’application configurés, l’enfant peut utiliser en complète autonomie son smartphone, sans surveillance ou intervention de ses parents. C’est à lui de gérer le temps d’utilisation qui lui est attribué, en alternant des phases d’utilisation et des phases de rechargement.

Afin de s’assurer que l’enfant dépose bien son portable lorsqu’il ne l’utilise pas, nous devons détecter avec précision le temps passé par le téléphone sur la borne. Nous avons donc opté pour une technologie de communication en champ proche dont la plupart des portables actuels sont équipés, NFC, ce qui nous permettait de ne pas ajouter d’autre capteur sur le portable de l’enfant. Ce choix est justifié en plus ample détails dans la partie application de la réalisation.

 

Réalisation

 

La borne

 

La borne est composée d’une structure en contreplaqué, d’un hub 5 USB et de son alimentation, ainsi que de 3 tags autocollants NFC NTAG215. Le choix du contreplaqué comme matériau est justifié par son prix relativement bas, par sa compatibilité avec la découpe laser, ainsi que par le fait qu’une couche de 3mm laisse passer le signal NFC.

La structure est construite à partir de 10 couches de contreplaqué, empilées et collées les unes aux autres dans un ordre précis. Elles ont pour dimensions 20x30cm, avec des épaisseurs variables. Certaines sont découpées ou gravées à la découpe laser selon des plans 2D dessinés sous Inkscape. Dans l’ordre, de haut en bas, voici les couches :

  • 1 planche de 3 mm avec la gravure « Schéma HYPN 1 2 3 »
    C’est le “haut” de la boîte, présentant le nom du projet et les différents emplacements pour les téléphones.
  • 1 planche de 5 mm avec la découpe « Schéma NFC »
    C’est la seconde couche, découpée pour laisser la place de coller les tags NFC directement sous la première couche.
  • 1 planche de 5 mm sans découpe
    Il s’agit juste d’une couche intermédiaire.
  • 1 planche de 5 mm avec la découpe “Schéma USB sans fil”
  • 2 planches de 3 mm avec la découpe du « Schéma USB avec fil »
  • 1 planche de 5 mm avec la découpe “Schéma USB sans fil”
    Ces 4 planches “USB” sont découpées de façon à pouvoir intégrer notre hub USB et son alimentation. Les dimensions et l’épaisseur ont été choisies spécifiquement par rapport à ce hub USB. Il faudra les adapter pour l’utilisation d’un autre hub USB.
  • 2 planches de 5 mm sans découpe
  • 1 planche de 3 mm sans découpe

Tous les plans de découpe sont disponibles ici.

Schéma de la structure de la borne

 

L’application Android

L’application a été développée pour les smartphone Android sur Android Studio. Le code est disponible sur GitHub ici.

Le blocage du téléphone

 

Une fonctionnalité principale de l’application est le blocage du téléphone pour des durées déterminées.

Nous voulions tout d’abord essayer de créer une application en mode kiosque, mais cela n’était pas fonctionnel et ne donnait pas au final l’effet escompté. Il a donc au final été choisi de créer d’une fenêtre popup englobant tout l’écran et se plaçant au-dessus des autres applications. Pour mieux comprendre, c’est le même système utilisé pour les bulles de discussion Messenger, sauf que cette fois, la “bulle” occupe tout l’écran du téléphone.

Cette fonctionnalité est couplée avec la fonctionnalité de minuteur interne mesurant le temps d’utilisation du téléphone. Au bout du temps d’utilisation déterminé par le parent via les paramètres, le téléphone se bloque.

 

Les minuteurs internes

Afin de calculer le temps d’utilisation du téléphone, nous avons créé un premier minuteur affiché sur la page principale de l’application (CountDownTimer). Lorsque l’on quitte la page de l’application, il y a deux possibilités : l’écran du téléphone est encore allumé et l’on navigue encore dessus ou l’écran du téléphone est éteint et le portable est verrouillé. Dans tous les cas, le minuteur est stoppé et le temps auquel il s’est arrêté est enregistré. Lorsqu’on ouvre l’application de nouveau, si l’écran était éteint, on reprend le minuteur là où il s’est arrêté. Si l’écran était allumé, on reprend le minuteur mais on met à jour le temps affiché avec le temps passé sur l’écran. Ainsi, le temps d’utilisation a été comptabilisé. Le temps passé hors application est compté via un second minuteur non affiché dans l’application.

La réalisation du chronomètre (Chronometer) correspondant au temps de charge a été commencée, mais non reliée à la reconnaissance du tag NFC.

 

La communication NFC

La communication NFC se fait grâce à des tags NFC NTAGS215. Les tags sont au préalable programmés afin d’activer l’application HYPN lorsque le smartphone est déposé sur la borne.

Les tags se situent respectivement sous la couche sur laquelle se trouve l’emplacement réservé aux smartphones.

Comme indiqué dans la présentation de la solution, nous avons fait le choix de la technologie NFC pour communiquer avec l’application. Nous voulions une technologie à courte portée et nous avions donc notamment le choix entre NFC et RFID. NFC a été préféré car de plus en plus de téléphones possèdent la technologie de lecture du tag NFC intégrée. De plus, la portée du NFC est de maximum 10 cm alors que celle du RFID est de minimum 10cm. Comme le téléphone doit être en contact direct avec la borne, le NFC semble plus indiqué.

 

Le réglage des paramètres

 

Les parents peuvent régler les paramètres de l’application via une authentification par mail et mot de passe. Le tout est géré par Firebase. Des paramètres par défaut sont générés avec la création du compte.

Les paramètres à régler sont l’heure de début, l’heure de couvre-feu, l’heure de fin, le temps d’utilisation et le temps de charge (voir explication des termes). Les données sont enregistrées dans la base de données pour chaque compte parent, puis récupérées dans la page principale pour les minuteurs et autres fonctionnalités.

 

Prise de recul

 

À cause d’une mauvaise gestion des priorités dans le développement, certaines fonctionnalités clé n’ont pas pu être implémentées complètement. En effet, bien que le contact avec le tag NFC de la borne ouvre notre application mobile, cela ne recharge pas le temps d’utilisation du portable.

Le blocage du smartphone est également à peaufiner : certains tests critiques n’ont pas été faits, comme l’arrêt forcé du l’application, ou la mise en veille automatique de certaines fonctionnalités lorsque le portable est en sur-consommation.

 

 

Résultat

 

Démonstration de la borne

 

 

Démonstration de l’application

 

La vidéo de démonstration de l’application étant trop lourde, vous pouvez la consulter ici.

 

 

Perspectives

 

Le plus important à ce point là du développement et de résoudre les problèmes qui apparaissent lorsque l’application passe en arrière-plan ou est fermée. En effet, le blocage ne se fait que lorsque l’application repasse au premier plan. Pour remédier à cela, il faudrait créer un service afin que l’application tourne tout le temps en background. Il faudrait ensuite déplacer les méthodes dans ce service pour qu’elles puissent être exécutées lorsque l’application n’est pas en premier plan. Cela devrait permettre de résoudre le problème actuel et c’est la première chose à faire dans un futur proche.

 

Une autre fonctionnalité primordiale serait de pouvoir programmer HYPN de sorte à ce que lorsque le tag NFC est reconnu, le compteur du temps de recharge soit automatiquement déclenché. Le lien entre les deux compteurs de temps de rechargement et temps d’utilisation est aussi à implémenter.

 

Dans un futur plus lointain, l’idée est de pouvoir bloquer non pas tout le téléphone mais certaines applications. C’était une fonctionnalité voulue dès l’idéation de la solution car nous ne voulions pas un blocage trop contraignant, ce qui pourrait susciter du mécontentement dans l’utilisation de cette solution. Cela n’a pas été possible dans un souci de complexité.