Solution technique : STOPCAR

par     Antoine VIOLLEAU        Eliot WALTER      Nantenin Sibidé     Kliser Javier REYES     Amaury Bernardin

1. Mise en contexte du projet

Dans le cadre du projet fil rouge de la TAF, Conception d’objets utiles, accessibles et durables de l’école d’ingénieur IMT Atlantique, nous avons travaillé sur un projet ayant pour but de mettre en relation un conducteur et un passager empruntant le même chemin afin de réduire le nombre de voitures vides et pour instaurer un climat de confiance.

La problématique des transports est au cœur de notre société actuelle, en centre urbain les mobilités douces et transports en commun sont naturellement plébiscités. Mais en bordure des périphéries, quelles solutions existent ? 

Lors de nos observations sur le terrain à des points stratégiques nous avons remarqué que la plupart des voitures circulent vides. Seul le conducteur est à bord d’une voiture, qui peut accueillir au moins 3 personnes de plus. C’est ce chiffre : 75% de l’énergie utilisé par nos voitures sert à transporter des sièges vides, du gouvernement (observatoire.covoiturage.gouv.fr) qui nous a motivé à concevoir une solution.

Après la phase d’enquête terrains, nous avons relevé deux enjeux majeurs pour une solution : facilité d’utilisation et flexibilité. Lors d’un trajet quotidien, le retard n’est pas admissible et il n’est pas envisageable d’avoir à préparer son trajet sur une application. 

Notre solution doit donc répondre à la problématique de l’autosolisme tout en respectant des critères stricts de flexibilité.

2. Présentation générale de la solution

3. Présentation générale de la solution

Notre solution s’appuie sur les réseaux mobiles. Nous avons en effet choisi ce standard de communication pour nos bornes de covoiturage pour plusieurs raisons. D’abord car dans un monde où la solution serait commercialisée, nous devrions avoir un nombre conséquent d’appareils sur une zone géographique très large. Le plus accessible dans ce cas-là est de se baser sur un protocole existant, qui ne nécessite pas d’infrastructure à déployer. En faisant le choix des réseaux mobiles, nous n’avons qu’à souscrire un abonnement auprès d’un opérateur mobile, et le quote de données n’a pas besoin d’être important. Nous échangeons peu de données, à chaque passager enregistré qui attendra 5 minutes, 1ko de données sont reçues/envoyées. Avec un quota offert de 100Mo, nous pouvons donc en théorie gérer 1 million d’utilisateurs par mois, par borne. 

Ces données sont communiquées à l’API ThingSpeak, notre site web utilise également cet API pour communiquer avec nos bornes connectées. L’utilisation de ThingSpeak est très simple et gratuite. Mais cela a rendu simple notre prototypage, cependant dans le cadre d’une réelle solution nous aurions développé un API REST qui remplit les mêmes fonctions mais un peu plus flexible sur les quantités de données autorisées. Nous n’avons pas choisi cette dernière solution, car cela aurait rendu le développement de la borne dépendant de celui du site-web, dans le temps imparti pour le projet cela aurait été difficilement réalisable.

Finalement, notre site-web est déployé sur un serveur web au ReSEL, le fournisseur internet associatif de l’IMT Atlantique. Le choix s’est tourné vers eux car le service est gratuit et simple. En effet, grâce à l’utilisation de leur dépôt gitlab, nous pouvons déployer en quelques clics notre service web. Cela a, dès le début défini des critères sur l’application développée : elle doit être “containerisée”. 

Figure 3. Diagramme de l’architecture de communication du système.

4. Matériel utilisé et montage électronique

  4.1 Matériel utilisé

• Arduino UNO
• Powerbank 5v
• Shield SIM900 GSM/GPRS
• SIM card avec du crédit (SMS et Internet)
• Antenne
• 2 protoboard
• 5 Tactile Momentary Push Button
• Jumpers 
• Boite plastique
• Module E-Ink 2,9 » 13339

  4.2 Montage électronique

Dans l’image suivante, le schéma de connexion entre les différents composants du système implémenté est présenté. Il comprend un module E-paper communiqué avec un Arduino Mega via le protocole de communication SPI. De plus, il comporte 5 boutons connectés en configuration pull-down pour garantir deux états logiques à l’aide de boutons normalement ouverts. En outre, la carte Shield SIM900 GSM/GPRS est connectée à l’Arduino Mega par les ports de transmission et de réception.

Figure 4.2. Schéma de connexion des composants du système.

Ci-dessous, le fonctionnement et l’importance de chaque connexion entre les différents composants du schéma de connexion de la figure 4.2 sont décrits.

Connexion entre la carte Shield SIM900 GSM/GPRS et l’Arduino Mega

La carte Shield SIM900 est connectée à l’Arduino Mega via les broches TX et RX. La broche TX de la carte SIM900 est reliée au RX1 de l’Arduino Mega (broche 19), et la broche RX de la carte SIM900 est reliée au TX1 de l’Arduino Mega (broche 18). Enfin, les broches d’alimentation VCC et GND de la carte sont connectées aux broches VCC et GND de l’Arduino.

Connexion entre le module E-paper et l’Arduino Mega

Ci-dessous, un tableau détaille les connexions entre le module E-paper et l’Arduino.

Module E-paper	Arduino Mega
DIN (Data In)	Pin 51
CLK (Clock)	Pin 52
CS (Chip Select)	Pin 53
DC (Data/Command)	Pin 6
RST (Reset)	Pin 7
BUSY	Pin 8

Explication du contrôle et du signal du module E-paper

• DIN (Data In) : Le pin DIN correspond à l’entrée de données du module E-paper. Il est connecté au pin 51 de l’Arduino Mega pour transmettre des données de l’Arduino vers le module. Le pin 51 de l’Arduino est une sortie numérique faisant partie du protocole de communication SPI.

• CLK (Clock) : Il s’agit du pin d’horloge. Il est connecté au pin 52 de l’Arduino Mega et est utilisé pour synchroniser le transfert de données, en envoyant des impulsions qui indiquent le moment où les données doivent être lues ou écrites. Le pin 52 de l’Arduino Mega est également un pin numérique faisant partie du protocole SPI.

• CS (Chip Select) : Il s’agit du pin de sélection de puce. Il est connecté au pin 53 de l’Arduino Mega et est utilisé pour activer ou désactiver le module E-paper. Lorsque ce pin est à l’état bas, le module E-paper est actif et peut recevoir des instructions et des données.

• DC (Data/Command) : Il s’agit d’un pin numérique utilisé pour indiquer si les données envoyées sont des instructions de commande ou des données d’image. Le pin 6 de l’Arduino Mega est une sortie numérique.

• RST (Reset) : Il s’agit du pin de réinitialisation. Il est connecté au pin 7 de l’Arduino Mega et est utilisé pour redémarrer le module E-paper, permettant ainsi de réinitialiser ou de restaurer son fonctionnement.
• BUSY : Il s’agit du pin de signal de traitement. Il est connecté au pin 8 de l’Arduino Mega et est utilisé pour indiquer si le module E-paper est occupé à traiter une opération. L’Arduino peut vérifier ce pin pour savoir si le module est prêt à recevoir de nouvelles commandes ou données

Connexion des boutons en configuration Pull-down

Les cinq boutons utilisés sont configurés selon un schéma de pull-down, ce qui garantit qu’une broche maintient un état défini en tout moment. Si une broche de l’Arduino n’est pas connectée à une source de tension spécifique et est ‘flottante’, son état est indéfini, ce qui signifie qu’il peut changer de manière aléatoire en raison d’interférences électromagnétiques ou de bruits ambiants. Cette configuration est utilisée pour éviter les états indéfinis générés par les boutons, assurant un fonctionnement stable et fiable du circuit.

4.3 Boîtier contenant le dispositif

Ci-dessous, la boîte qui abrite le circuit électronique est présentée. Elle se compose d’une partie arrière et d’une partie avant. Les deux parties se superposent à la fin, la partie droite étant placée sur la partie gauche.

La boîte a été conçue dans SolidWorks et imprimée en plastique à l’aide d’une imprimante 3D Ultimaker. Son design est basé sur les dimensions des composants devant être installés à l’intérieur. De plus, elle est équipée d’un trou interne facilitant l’allumage et l’extinction du système, ainsi qu’un orifice pour la sortie de l’antenne, qui est connectée à la carte Shield SIM900 GSM/GPRS.

Figure 4.3. Modèle 3D de la partie avant et arrière de la boîte en plastique.

4.4 Description des logiciels avec lien vers le code

Technologies Utilisées dans le Projet STOPCAR

Django :
Django est un framework web Python populaire, permettant de créer rapidement des applications robustes et sécurisées. Dans ce projet, il sert de base pour le site web de covoiturage, avec une configuration centralisée dans le fichier settings.py. Django est également optimisé pour les appareils mobiles, facilitant l’adaptation du site à différents formats d’écran.

Docker & Docker Compose :
Docker permet de créer des environnements isolés pour les applications, garantissant leur portabilité et simplifient les déploiements. Docker Compose est utilisé pour gérer plusieurs services en parallèle, comme le site web, la base de données, et phpMyAdmin, dans des conteneurs distincts mais interconnectés.

MySQL & phpMyAdmin :
MySQL est utilisé pour la gestion des données (utilisateurs, trajets, etc.). Pour faciliter l’administration de la base de données, phpMyAdmin offre une interface web intuitive permettant de consulter et de modifier les données en temps réel.

Progressive Web App
Le site-web permet l’installation d’une PWA. Lorsqu’un utilisateur se connecte sur le site, son appareil lui propose de l’installer sur son téléphone. Assez peu de travail est nécessaire, et on a vraiment l’impression d’avoir affaire avec une application native.
Cela permet également l’envoi de notifications push, ce que nous n’avons pas eu le temps de réaliser. 

 

Modèle MVC dans Django

Django suit un modèle similaire à MVC (Modèle-Vue-Contrôleur), mais avec une légère variation. Le modèle Django utilise les termes Modèle, Vue et Template pour organiser l’architecture du projet.

1. Modèle (Model)
Le modèle est le fichier où l’on définit les classes représentant les données de l’application. Chaque classe dans ce fichier correspond généralement à une table dans la base de données, et ses attributs sont les colonnes de cette table. Par exemple, dans notre projet, le fichier models.py contient la définition des classes comme Trajet, Utilisateur, etc. qui décrivent les objets à stocker et manipuler dans la base de données.

2.Vue (View)
En Django, la Vue joue en réalité le rôle du Contrôleur dans l’architecture classique MVC. Elle se trouve dans le fichier views.py. La vue reçoit les requêtes de l’utilisateur, interagit avec les modèles pour récupérer ou manipuler des données, puis renvoie une réponse appropriée. Cela inclut l’appel aux API externes, l’extraction des informations de la base de données et l’envoi des données aux templates pour affichage. La vue fait donc le lien entre le modèle (données) et le template (interface utilisateur).

3.Template (Template)
Le template dans Django représente la Vue dans l’architecture MVC classique. Il se trouve dans le répertoire templates et contient le code HTML qui définit la structure de l’interface utilisateur. Les templates sont remplis avec les données envoyées par la vue, et ils affichent ces informations à l’utilisateur sous forme de pages web dynamiques.

 

Utilisation des API Externes

Notre projet intègre plusieurs API externes pour améliorer l’expérience des utilisateurs, en facilitant la géolocalisation, la gestion des trajets et la communication avec la borne. Voici les principales API utilisées :

1. ThingSpeak
   ThingSpeak est une plateforme IoT qui permet de collecter, stocker et analyser des données issues de capteurs et appareils connectés. Dans ce projet, elle est utilisée pour la communication avec la borne Arduino MEGA, permettant de récupérer et mettre à jour les données de trajets en temps réel.

• • ride_list : Cette fonction récupère les données des trajets depuis ThingSpeak.
  • accept_ride : Lorsqu’un conducteur accepte un trajet, la borne met à jour les informations sur ThingSpeak pour refléter le changement.
• Nominatim (via l’API OpenStreetMap)
  Nominatim est un service de géocodage et de géocodage inversé permettant de convertir des adresses en coordonnées géographiques et inversement.
• • create_driver_ride_request : Utilisé pour localiser le conducteur et le passager au moment de la création du trajet. L’API convertit les informations de localisation en coordonnées géographiques.
  • reverse_geocode : Permet d’obtenir la localisation précise d’un point à partir de ses coordonnées GPS, essentiel pour déterminer l’emplacement exact des passagers et des conducteurs
• Google Maps API
  L’API Google Maps permet d’accéder à divers services de cartographie, dont la calcul de distance et de durée de trajet entre deux points.
• • get_trip_duration : Cette fonction calcule la durée d’un trajet en utilisant les informations récupérées depuis ThingSpeak, en intégrant les données géographiques et le calcul d’itinéraires via Google Maps.

Lien vers le dépôt Git :
Le code source complet du projet est disponible sur GitLab.

 

4.5 Justification des choix techniques ; difficultés et solutions de contournement

Justification des choix techniques 

Pourquoi utiliser l’Arduino Mega ?

La carte de développement Arduino Mega possède une plus grande capacité de stockage par rapport à d’autres dispositifs comme l’Arduino Uno. De plus, elle offre un plus grand nombre de broches digitales et analogiques ainsi qu’une plus grande facilité pour connecter et manipuler des cartes de réseaux mobiles, telles que la carte Shield SIM900.

Pourquoi utiliser un module E-paper ?

Pour ce projet, un module E-paper a été sélectionné en raison de sa faible consommation d’énergie et de son excellente lisibilité dans diverses conditions de luminosité, y compris en plein soleil. Sa technologie permet de maintenir l’image visible sans consommation d’énergie continue. Cette technologie est idéale puisque le prototype développé utilise une batterie avec un stockage d’énergie limité. De plus, en affichant des informations statiques ou avec peu de mises à jour, le module optimise davantage la consommation énergétique, contribuant ainsi à prolonger la durée de vie de la batterie du système mis en place.

Pourquoi utiliser une carte Shield SIM900 GSM/GPRS ?

La carte Shield SIM900 GSM/GPRS permet la connectivité aux réseaux mobiles pour envoyer et recevoir des données, des appels ou des SMS. Cette carte permet l’accès à Internet pour la transmission de données. En se connectant à des cartes comme Arduino, elle facilite la mise en place de la communication sans fil, en particulier là où l’infrastructure Internet est limitée ou inexistante.

Difficultés au niveau matériel :

• Problèmes avec la première version de la boîte en plastique : La version initiale de la boîte a présenté des problèmes de conception, ce qui a nécessité du temps supplémentaire pour réaliser les ajustements nécessaires et l’adapter correctement au projet.
• Communication entre l’ESP32 et le module E-paper : Des difficultés ont été rencontrées pour établir la connexion entre le microcontrôleur ESP32 et le module E-paper, en raison de la complexité de l’intégration entre les deux dispositifs et du manque de documentation disponible à ce sujet.
• Communication entre l’Arduino et le module E-paper : Au départ, quelques problèmes mineurs ont été rencontrés lors de la tentative d’établissement d’une communication efficace entre l’Arduino et le module E-paper. Cependant, ces problèmes ont été résolus.
• Limitations de stockage sur l’Arduino Uno : La mémoire flash de l’Arduino Uno s’est révélée insuffisante pour stocker les multiples images nécessaires au module E-paper. Ce problème a conduit à la décision de passer à un Arduino Mega, qui offre une plus grande capacité de stockage et permet de répondre aux besoins du projet.

Difficultés au niveau logiciel :

• La compréhension de l’objectif réel : au début, il était difficile de voir où nous allions, mais la phase de production a été plus simple, nous avions une idée et savions plus ou moins dans quelle direction nous orienter.
• Géolocalisation : Il a fallu récupérer les données de localisation automatiquement au chargement de la page, sur téléphone et sur ordinateur. La manière de faire était différente selon les cas d’utilisation, il a fallu s’adapter.
• Intégration du modèle de base de données depuis django: Au départ, on ne connaissait pas bien la technologie, donc il a fallu apprendre. Sous Django, la base de données est créée à partir du code, c’est quelque chose que je ne connaissais pas, mais on a dû s’adapter, apprendre et reconnaître. 
• Récupération de la clé api Google pour connaître la durée des trajets pour l’algorithme de matching : Pour l’algorithme de matching, il fallait trier par durée les trajets, donc on a dû utiliser une clé d’API Google Maps pour demander à Google de calculer la durée et nous la rendre. On a dû créer un compte pro Google pour cela.

 

5. Perspectives

Dans un scénario avec plus de temps disponible, nous aurions aimé intégrer les aspects suivants au projet :

Au niveau matériel :

• Connexion d’un panneau solaire : Une idée intéressante à mettre en œuvre dans un futur travail est d’implémenter un système d’alimentation autonome pour l’Arduino en utilisant un panneau solaire. Cette solution permettrait au dispositif de fonctionner de manière indépendante des sources d’énergie traditionnelles.

Le design inclurait un panneau solaire capable de générer suffisamment d’énergie pour maintenir l’Arduino et ses composants périphériques. De plus, l’idée serait d’intégrer un système de stockage d’énergie, comme des batteries rechargeables, accompagné d’un régulateur de tension pour garantir un approvisionnement constant de 5V au dispositif, même en conditions d’éclairage variables.

• Connexion d’une bande LED : Une amélioration à envisager pour les futures phases du projet est l’implémentation d’une bande LED, afin d’augmenter la visibilité de la borne et de faciliter son identification par les utilisateurs, notamment dans des conditions de faible éclairage. 

Bien que cette mise en œuvre n’ait pas été possible à ce stade en raison de contraintes de temps, elle reste une solution viable pour les phases futures, améliorant ainsi de manière significative l’expérience utilisateur et l’efficacité du système.

Au niveau logiciel :

• Uniformité du code : organiser le code, car la structure actuelle n’est pas cohérente, c’est-à-dire que tous les éléments ne sont pas écrits de la même manière, et parfois des formules différentes sont utilisées. Comme travail futur, l’idée est de standardiser le code pour obtenir une plus grande uniformité.
• Améliorer l’expérience utilisateur (UX) : la proposition consiste à intégrer des fenêtres contextuelles au lieu de se limiter à des liens redirigeant vers d’autres pages. De plus, il est souhaité de rendre l’interface utilisateur plus attrayante et visuellement agréable.
• Mise en place d’un système de géolocalisation : L’idée est d’implémenter un système de géolocalisation en temps réel permettant au passager de voir sur la carte la position actuelle de son chauffeur.
• Notification push pour chaque événement : Pour valider les trajets, on met à jour l’API et à ce moment-là, on pourrait notifier l’utilisateur en lui envoyant une notification push sur l’application. Nous n’avons pas eu le temps de le faire.
• Amélioration de l’algorithme de matching :
  Nous prévoyons de travailler sur un algorithme de matching plus performant, incluant de nouvelles options pour les conducteurs, telles que :

• • Filtrage par durée maximale : Le conducteur pourra définir une durée maximale pour son trajet, en précisant s’il souhaite ou non effectuer des allers-retours.
  • Modes de véhiculage : Le conducteur pourra choisir parmi différents modes de transport, optimisant ainsi la compatibilité avec les passagers.
  • Filtrage par itinéraire : Des améliorations seront apportées pour permettre au système de proposer des passagers se trouvant directement sur la route du conducteur, grâce à l’intégration de nouveaux algorithmes plus précis et efficaces.

 

6. Résultats

6.1 Le dispositif

Après avoir assemblé le montage électronique à l’intérieur de la boîte en plastique, le dispositif est visible sur l’image 6.1.

Figure 6.1. Dispositif assemblé dans la boîte en plastique.

Quelques images du fonctionnement du système sont présentées dans les figures 6.2 et 6.3.

Figure 6.2. Un passager a sélectionné le trajet vers Technopole.

Figure 6.3. Un passager souhaite annuler un trajet qu’il avait sélectionné.

Sur l’image 6.1, on voit la borne conçue pour être utilisée par les utilisateurs du système de transport partagé. Ce dispositif sert d’interface de communication entre l’utilisateur et le conducteur.

La borne comprend trois boutons bleus permettant à l’utilisateur de sélectionner différents trajets en fonction de sa destination. De plus, elle dispose d’un bouton vert pour confirmer la sélection du trajet et d’un bouton rouge pour l’annuler.

L’appareil est équipé d’une antenne reliée à une carte Shield SIM900 GSM/GPRS, ce qui lui permet de se connecter au réseau mobile. Il comprend également un interrupteur situé à gauche de l’antenne, facilitant l’allumage et l’extinction du système.

Enfin, la borne est dotée d’un module E-paper qui affiche à l’utilisateur les actions effectuées avec les boutons, offrant ainsi une expérience interactive et claire.

 

6.2 Conclusion et remerciement

Conclusion

Pour conclure, notre projet a abouti à la création d’un objet connecté robuste et économe en énergie, associé à un site web interactif pour offrir une solution de covoiturage spontané. La borne connectée, bien qu’efficace, présente quelques limites de réactivité dues à l’écran e-paper nécessitant plusieurs secondes pour se rafraîchir, ainsi qu’à l’architecture monothread de l’application, empêchant l’exécution de plusieurs tâches simultanées. Avec davantage de temps, ces aspects auraient pu être optimisés.

Du côté du site web, nous sommes particulièrement satisfaits d’avoir réussi à le déployer en tant que PWA (Progressive Web App), ce qui permet de l’utiliser comme une application native sur Android et iOS, renforçant ainsi l’expérience utilisateur.

Remerciements

Nous tenons à remercier chaleureusement nos professeurs et encadrants de l’IMT Atlantique pour leur accompagnement tout au long de ce projet. Leur expertise et leur soutien ont été essentiels pour relever les défis techniques et conceptuels de cette aventure. Ce projet a également été l’occasion de travailler en équipe et de mettre en pratique nos connaissances pour concevoir une solution durable et utile.

Vidéo d’explication du fonctionnement de notre solution. 

Partie 1 : Interaction uniquement entre l’application web

Partie 2 : Interaction application web et borne

Site web déployé : https://stopcar.projet.resel.fr/

Series Navigation

<< STOPCAR – Synthèse de l’enquête terrain et personas