Ce projet a été réalisé lors de ma 3ème année d’étude, en Bachelor Développeur Web à HETIC.
À la base, il devait s’agir d’une course en fin d’année avec les différents groupes de l’école. Ça ne s’est pas fait, mais c’est important de l’avoir en tête car il fallait donc réfléchir à un code qui fonctionne, certes.
Mais également réfléchir à si on privilégie la vitesse, la maniabilité etc… C’est donc aussi de la stratégie.
Pourquoi le projet s’appelle « Turbotron32 » ?
Ce n’est pas l’école qui a choisit ce nom, ça a été penser en équipe.
« Turbo » pour la vitesse, « Tron » pour faire référence au film et « 32 » car c’est basé sur un ESP32.
Description
Il s’agit du projet de fin d’année, il fallait développer une application web / mobile permettant de contrôler une petite voiture de la marque Freenove équipée d’un ESP32, montée et fourni par l’école.
Il y avait différents critères de notation :
– Premièrement, il fallait pouvoir contrôler la voiture, voir les données télémétriques qu’elle renvoie et voir à travers sa caméra via l’interface que nous devons développer.
– Deuxièmement, il fallait avoir la possibilité d’avoir un mode de suivi de ligne.
Caractéristiques
Le véhicule était équipé de :
ESP32 : Un microcontrôleur qui sert de cerveau au véhicule, c’est lui donne les ordres aux autres composants et c’est par lui qu’on passe lorsque l’on veut interagir avec le véhicule depuis notre application web / mobile. Il est compatible Wifi et Bluetooth, on a privilégier la connexion Wifi pour avoir une plus grande portée et ne pas avoir à courir derrière le véhicule lors de la course de fin d’année.
Sonar : Un sonar permettant de savoir si il y a un obstacle sur le trajet et ainsi arrêter le véhicule si c’est trop proche.
Caméra : Pour voir à travers le véhicule et facilement le contrôler à distance.
Suivi de ligne : Il s’agit de capteurs infrarouges qui permettent de suivre une ligne noir au sol.
Pour ce projet, le professeur a donné une base d’API pour la voiture afin de tester son bon fonctionnement et avoir une certaine base. On l’a modifiée à notre sauce au fil du temps.
On était 7 personnes dans l’équipe et on a tous toucher à chaque aspect du projet, que ce soit par curiosité, pour aider quand il y avait besoin mais également pour que personne ne soit perdu le jour de la soutenance, peu importe les questions qui sont posées.
Mais dans les grandes lignes, c’était composer comme ceci :
Gestion du projet
Pour ce projet, comme c’était quelque chose de nouveau, que ce soit le fait de contrôler un objet physique en projet IoT (Internet des objets), la réceptions de données MQTT pour les données télémétriques, on n’a testé qu’une seule fois le websocket avant de faire ce projet etc…
Il nous a semblé plus judicieux de couper le projet en plusieurs étapes et utiliser une méthodologie Kanban pour plus de flexibilité.
On avait un Jira pour se répartir les tâches et voir ce qu’il restait à faire, un Github pour partager le code de chacun et Discord pour communiquer entre nous.
Fonctionnement
React Native : On a décidé d’utiliser React Native pour avoir à la fois une app web et mobile à partir d’un seul code et ainsi gagner du temps.
Broker MQTT : les informations MQTT, ce sont les données télémétriques de la voiture, les données du sonar, des capteurs infrarouges par exemple.
On a choisit d’utiliser Mosquitto, un projet open source simple et efficace. L’avantage d’un Broker, c’est que la voiture n’a besoin de communiquer qu’avec lui et non pas directement avec le frontend ou le backend ce qui simplifie le développement et les évolutions à venir mais améliore également les performances dans ce cas là car un ESP32 a une puissance de calcul limitée, il ne faut pas trop le surcharger.
Ici, c’est Mosquitto qui gère la liaison du MQTT de la voiture avec le frontend et avec le backend.
Python : Il sert de serveur pour calculer la force à mettre dans les roues pour que la voiture suive correctement la ligne.
Difficultés et améliorations
Le temps
Il y a une chose qui faut garder à l’esprit, c’est que ce projet est basé sur la voiture, un objet physique. On ne pouvait donc pas tous avancer comme nous aurions pu le faire avec un projet web classique, il faut pouvoir tester le code sur la voiture ce qui implique une contrainte technique.
Avec un rythme d’alternance de 3 semaines entreprise et 1 semaine école, ce n’est pas si simple.
Vous pouvez vous dire qu’il suffit de se déplacer voir les autres pendant notre temps libre mais… Sachant que chacun a déjà ses propres occupations, moi j’étais en Normandie pour le travail, pas sur Paris donc pas possible ! 😭
Vers la fin du projet, on a quand même pris le risque de se l’envoyer par la poste les uns les autres pour avancer comme on voulait. Je dis bien un risque car… Les objets perdu, ça existe et que la voiture n’est pas en Tungstène, elle est fragile. :p
Voilà pourquoi la vidéo où je montre le suivi de la voiture se passe dans ma chambre.
De nouveaux concepts
Assimiler de nouveaux concepts, ça va. Mais quand il y en a pas mal et que le problème peut aussi bien venir d’un problème technique en réseaux, sur la voiture ou dans le code, c’est déjà plus complexe. Pas infaisable, mais complexe.
Je m’explique, voici quelques exemples :
- L’ESP32 a besoin d’être connecté sur du Wifi 2.4G pour fonctionner, il n’est pas compatible avec du Wifi 5G. Ça encore ça va, comme je suis un peu bidouilleur j’en avais déjà entendu parler et j’ai pu aider mon groupe, mais quand on s’y attend pas, ça peut être frustrant.
- La batterie du véhicule se déchargeait assez rapidement et en fonction de ça, ça jouait sur nos tests. Par exemple, la voiture s’allumait mais n’acceptait pas de se connecter au Wifi avec un seuil trop bas. La vitesse des roues est aussi dépendante de la batterie et autres…
- Utiliser du MQTT pour la première fois, c’était pas si simple que ça en a l’air, il fallait le temps de bien comprendre le fonctionnement et utiliser des outils pour comprendre d’où venaient les problèmes. C’est la voiture qui n’envoie pas les informations ? Mosquitto (le broker) ? Sans oublier la réception du websocket où on devait tester avec Postman.
- L’ESP32 a des limites physiques, il n’a pas une puissance de calcul illimité, récupérer le flux vidéo c’est assez lourd, sans parler des contrôles du véhicule, le mieux ça aurait été avec un Raspberry Pi par exemple car c’est plus puissant.
- Le Joystick était tout de même assez majeur pour ce projet, c’est avec lui qu’il fallait jouer sur la maniabilité et/ou la rapidité. De plus, il n’y avait pas de librairies qui nous convenaient vraiment, on a donc fait un fork d’une librairie pour répondre au mieux à nos attentes sans devoir ré inventer la roue.
Résultat du Joystick :
Backend python
Le mieux aurait été d’inclure le serveur de suivi de ligne directement dans la voiture et non pas avec un serveur à part. Ça aurait été plus simple que ce soit pour le déploiement, une meilleure optimisation car la voiture n’a pas à attendre une réponse externe pour agir.
Alors pourquoi ce choix ? Il ne restait plus beaucoup de temps pour finir le projet, à choisir entre quelque chose d’optimiser mais non fini et quelque chose qui fonctionne correctement bien que moins performant, j’ai choisi la deuxième option, le groupe étant d’accord avec ce choix.
À ce moment, j’avais déjà l’information que la course n’aurait pas lieu et que donc, la partie déploiement n’était plus une grosse préoccupation.
J’ai choisi Python car c’est ce que j’utilisais en entreprise, j’étais donc plus à l’aise avec.
Résultat du serveur Python:
Résultat final
Lors du passage avec le jury, qui était un passage individuel, j’ai eu 18.73/20.