Il y a 6 mois -

Temps de lecture 9 minutes

XebiKart 1 an après

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 (CNNconvolutional 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, comme par exemple celui ayant réussi à voter pour l’avenir du monde à représenter en réalité augmentée… Et vous, vous pensez à un avenir rempli de zombies minecraftiens ou de bouées licornes ?

Mais ce n’est pas tout ! Le dashboard nous a également permis d’afficher l’état de la voiture, et ce avec un design évoluant au fur et à mesure de l’avancée dans le temps (si vous vous demandez de quoi nous parlons, allez jeter un coup d’œil à la vidéo de la keynote, vous y trouverez des voyages dans le temps digne de Retour vers le Futur !)

Ceci peut sembler simple au premier regard, mais n’oubliez pas que tout ces éléments étaient représentatifs de l’état de la voiture en temps réel, avec de forts challenges sur la représentation, comme par exemple celle de l’orientation des roues en 3D :

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

Mais ce n’est pas tout ! Qui dit réalité augmentée dit 3D, notion de profondeur, etc. Et il nous faut donc des objets en 3D à incruster en réalité augmentée afin de pouvoir naviguer autour, et non de simples images 2D. Pour cela, ça tombe bien : nous avons désormais des personnes dont c’est la spécialité, grâce au groupe Publicis et à ses différentes branches ! Et le résultat est sans appel :

Scène et logistique

Enfin et pour finir sur une note un peu moins technique, tout ce travail n’aurait pas aussi bien été mis en valeur sans un travail méticuleux sur l’environnement (scène, piste au sol, …) dans lequel a évolué la voiture de XebiKart.

Au delà du côté visuel, tout ceci a été réalisé pour des raisons pratiques et en lien direct avec des besoins “métier”, comme par exemple la couleur de la piste pour faciliter la reconnaissance d’image, ou la hauteur des bâches sur les côtés permettant au lidar de fonctionner.

Dépôts de code source

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 :

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 !

Publié par Alexis "Horgix" Chotard

Alexis "Horgix" Chotard est DevOps chez Xebia et s'intéresse particulièrement à tout ce qui est infrastructure moderne et dynamique (infra-as-code, containérisation, automatisation, self-healing, déploiement continu, ...). Alexis est également formateur au sein de Xebia Training .

Commentaire

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.