Il y a un an jour pour jour à peu près, nous vous présentions XebiKart lors de la keynote de la XebiCon’19 — vous savez, quand nous pouvions encore faire des conférences en présentiel à l’échelle du Palais Brongniart !
Petit rattrapage pour les absents : XebiKart, c’est notre projet délirant sur lequel nous nous sommes (littéralement) amusés afin d’en mettre plein les yeux au public de la XebiCon. Un projet de voiture autonome couplé à de la réalité augmentée et plein d’autres choses techniquement sympa. L’idée était pour nous de bosser ensembles, avec tout notre panel de compétences, sur un projet fun : du front, du back, du mobile, du machine learning, du cloud, de l’infra, de l’embarqué, … la liste est longue.
En cette fin d’année 2020, faute de XebiCon à cause de ce maudit contexte sanitaire, nous vous proposons de revenir sur XebiKart et de vous en montrer les entrailles en réalisant notre promesse faite sur scène : open sourcer les dépôts GitHub de ce projet !
Vous pouvez retrouver la vidéo de la keynote ici ou bien la présentation technique de la keynote ici.
L’organisation
On compte plus de 25 contributeurs, ayant passé 3 demies journées tous ensemble et 2 demies journées supplémentaires pour les 8 speakers. Mais l’essentiel du projet s’est fait grâce à l’investissement personnel (∞ soirées, midis, etc.)
Les participants étaient répartis en 5 “équipes” informelles (SI, Dashboard, Car, ML, AR) qui ont été épaulées par 2 Product Owners / Srum Master.
La Voiture
Difficile de faire un projet de voiture autonome sans voiture !
Après avoir envisagé et espéré pouvoir utiliser l’AWS Deepracer, nous avons été confrontés à la dure réalité : Amazon repoussaient encore et encore la date de disponibilité. Nous avons donc fini par construire notre propre voiture, qui, a défaut d’être plus jolie que l’AWS Deepracer, avait le mérite d’être présente et plus modulaire. Pour se faire, nous nous sommes basés sur le projet Donkeycar.
Concrètement, le résultat en terme de hardware est le suivant :
Rendre la voiture autonome
Pour pouvoir rendre la voiture autonome, nous avons développé une partie logicielle utilisant les informations données par les capteurs (le lidar et la caméra) pour gérer l’accélération et la direction des roues.
Traitement des images
Les images ne sont pas utilisées de manière brute par le modèle. Il est nécessaire de réaliser plusieurs traitement afin de dégager l’information pertinente qui pourra ensuite être exploitée par l’intelligence artificielle.
D’abord on “crop” l’image pour ne conserver que la partie porteuse du plus d’informations pertinentes pour le pilotage. On va donc ne conserver que la piste, la partie de l’image correspondant au public n’est pas essentiel ici.
Dans un deuxième temps on passe un filtre permettant de repérer les contours de la piste. Pour cela on va utiliser des techniques de edge detection qui vont permettre de repérer les contrastes de couleurs les plus importants, qui correspondent généralement au contours des éléments contenus dans l’image.
Un traitement additionnel est réalisé pour repérer des zones de couleurs particulières, pouvant par exemple correspondre à des obstacles.
Le pilote autonome
Pour conduire la voiture un programme Python est intégré dans le RaspberryPi embarqué dans la voiture. Ce programme utilise des modèles de deep learning entraînés pour adopter les bonnes actions au bon moment. Ce sont principalement des réseaux de neurones convolutifs (CNN – convolutional neural networks) qui sont utilisés, avec une architecture permettant de coupler les informations venant des deux sources : caméra et lidar.
La taille du modèle et ensuite optimisée pour pouvoir l’embarquer sur la voiture.
L’architecture logicielle
Mais la voiture n’est pas seule à travailler ! En effet, nous avions toute une partie back-end visant à remonter le flux vidéo d’une voiture à des fins d’entraînement des modèles de machine learning, et servant les informations pertinentes à un front-end servant de dashboard durant la keynote elle-même : vitesse de la voiture, orientation des roues, caméra live, etc. Nous avions même pensé intégrer une notion de “temps au tour” et se lancer dans des courses, mais cette idée a finalement été abandonnée.
D’un point de vue architecture logique, en voici le résumé :
-
La voiture produit des événements en temps réel en MQTT dans des topics RabbitMQ
-
Ce RabbitMQ est consommé par une application en Java/Kotlin basée sur le framework Spark et packagée via Docker
-
Un front-end en React servi via nginx vient requêter le backend, et ce dernier va même lui pousser des mises à jours en temps réel via un mécanisme de SSE
-
Tout ce beau monde est déployé sur du Kubernetes managé sur GCP au travers de GKE
-
Ces déploiements sont assurés via Helm
-
Le backend expose des métriques au format Prometheus
-
L’exposition des services est réalisée par Istio, et des Load Balancer managés sur GCP
-
Le chiffrement TLS (HTTPS) est réalisé via des certificats générés par Cert Manager auprès de Let’s Encrypt
-
Les records DNS sont gérés via External DNS à partir des annotations d’exposition
Un certain nombre de ces choix a été fait pour des raisons d’optimisation de notre temps. Qu’aurions nous changé si nous avions eu plus de temps, et au regard des évolutions en cette fin 2020 ?
-
Nous aurions probablement utilisé un autre broker de messages. Pas Kafka même si nous l’apprécions énormément – le cas d’usage ne nous paraît pas approprié. Probablement quelque chose comme VerneMQ, NATS ou autre.
-
Nous aurions réalisé le backend en Go, qui a su grandir en popularité chez Publicis Sapient cette année
-
Nous utiliserions un mix de Kustomize et Helm pour le déploiement, selon les composants, et non uniquement Helm
-
Nous ferions réellement du multi-cloud en déploiement tous nos composants à la fois sur GCP, sur AWS, avec peut-être un peu de Cloudflare quelque part
-
Nous rajouterions des fonctionnalités plus avancées et fun via du Functions-as-a-Service
-
Nous prendrions le temps d’ajouter du tracing via OpenTelemetry dans chacun de nos composants
Le Dashboard
Toute cette infrastructure est notamment visible au travers du dashboard, avec des modules assez originaux tels que le suivant (orientation des roues) :
Ajouter des éléments en réalité augmentée
Nous avions dès le départ comme ambition d’ajouter des éléments sur la piste de course en réalité augmentée, et de faire voter le public (merci le dashboard !) pour le choix de ces éléments. Plusieurs outils ont été utilisés pour ajouter du contenu augmenté au flux vidéo de départ :
L’une des techniques principales de réalité augmentée est l’odométrie qui utilise l’information envoyée aux actuateurs (moteurs) pour estimer le déplacement et l’orientation d’un acteur, par exemple un robot dans le temps.
L’odométrie visuelle utilise des séquences d’images venant d’un flux vidéo pour estimer la distance parcourue. L’O.V. calcule et suit les feature points dans la séquence et utilise des algorithmes de projection 3D pour en déterminer la distance. L’odométrie visuelle inertielle se sert d’une unité de mesure inertielle (IMU – gyroscope et accéléromètre) pour mieux calculer le déplacement.
Des modèles de Machine Learning sont également utilisés pour détecter la position des objets fixes et des objets mobiles.
De plus l’intensité de la lumière est capturée pour estimer la source lumineuse la plus forte, ce qui permet de dessiner les ombres et de dresser un décors cohérent
Dépôts de code source
-
Chose promise chose dûe, voici les dépôts de XebiKart, pas forcément tous 100% à jour, mais au moins vous pouvez aller voir sous la capot !
Conclusion
Vous trouverez tous les détails nécessaires dans les dépôts de code ci-dessus ainsi que dans les vidéos de la XebiCon’19 concernées :
-
La “keynote dev” où l’on vous explique plus en détails certains des éléments de cet article
-
Un slot dédié à l’infrastructure de XebiKart, avec un tour du code en live !
Au final, nous avons toujours un souvenir mémorable de cette expérience un an après – du fun et de la technique sans trop de prise au sérieux, pour un événement qui nous est cher, avec des collègues sympas et compétents; que demander de plus ?
On vous donne rendez-vous bientôt pour de nouvelles démos techniques, et vous souhaitons de bonnes fêtes dans l’interval !