Véhicule autonome : que propose la plateforme ouverte Apollo de Baidu ?

Les véhicules autonomes sont des sytèmes complexes. Pour les comprendre, les initiatives "open source" sont préciseuses. Elles offrent des informations vérifiables et des logiciels réutilisables. J'ai tenté dans cet article d'explorer celle de Baidu nomée Apollo. Au passage j'en mentionne quelques autres, mais je suis loin d'avoir épuisé le sujet. Le domaine reste très dynamique. N'hésitez pas à compléter en utilisant les commentaires et bonne lecture !


Apollo est une initiative du géant chinois Baidu visant à accélérer le développement des véhicules autonomes. Open Source, elle semble assez dynamique et progresse de semaine en semaine. Elle offre principalement des logiciels open source, mais aussi d'autres composants intéressants que j'évoque ci-dessous.

Un système complet de logiciels ouverts pour le véhicule

Un ensemble de logiciels est disponible sur GitHub. On y trouve notamment :
  • Un Système d'exploitation temps réel (RTOS), 
  • Un framework pour les applications utilisées par le véhicules,
  • Et les principales applications embarquées nécessaires à l'autonomie : gestion des capteurs, cartographie et localisation, planification de la trajectoire et controle du véhicule via le bus CAN, interface homme machine...
D'autres initiatives open source ont la même ambition, notamment AGL Automotive Grade Linux de la Linux Foundation. Notons au passage que ce sont les lorientais de iot.bzh qui sont les premiers contributeurs d'AGL. L'équipe a pouttant l'air de ne pas se prendre au sérieux  et ils embauchent (à Lorient en plus !).

Une version intégrée des différents logiciels, dite "end to end", permet de disposer d'une version de référence "clés en main" associée à un certain niveau de performance. Ainsi actuellement la version 2.5.0 possède les fonctions suivantes : This release allows the vehicle to autonomously run on geo-fenced highways. Vehicles are able to do lane keeping cruise and avoid collisions with the leading vehicles.  

Coma.ai crée  par George Hotz propose aussi un "agent de conduite" ouvert : Openpilot qui utilise une simple caméra. Openpilot offre des fonctions d'adaptative cruise control et de lane keeping assist system.

L'architecture générale retenue par Apollo permet de simuler l'ensemble des logiciels sur une configuration matérielle donnée, mais aussi d'intégrer dans la simulation des "composants matériels réels" qui permettent d'interagir avec la simulation. 

Cette simulation avec "hardware in the loop" est aussi l'objet de AirSim de Microsoft, open source aussi qui permet de simuler des drones, mais aussi des véhicules autonomes.

Une plateforme "harware" de référence

Cette plateforme comporte un véhicule Lincoln MKZ (marque de luxe propriété de Ford) intégrant un kit ADAS (Advanced Driver Assistance System), une centrale inertielle Novatel, un calculateur embarqué Astuff, un recepteur GNSS ProPak et son antenne, une carte de communication CAN ESD et un Lidar Velodyne.

Des services hébergés : cloud services

Il s'agit de services en ligne du catalogue de Baidu sur lesquels s'appuient les briques logicielles embarquées. Cette offre se compare à celles des géants américains comme Google ou Amazon par exemple et bien entendu elle n'est ni ouverte ni gratuite... Il s'agit notamment :
  • d'une carte haute définition, 
  • des services géolocalisés et On line travel agency (OTA), 
  • des services d'IA (DuerOS) utilisés notamment pour de la reconnaissance d'image ou du langage naturel,
  • mais aussi de fonctions de sécurité.

Des données

La plateforme propose plusieurs ensembles de données annotées manuellement et utiles pour l'apprentissage des différentes briques logicielles. On y trouve par exemple :

Pour l'apprentissage
  • des nuages de points Lidar et des images de caméras annotées pour la détection et la classification des obstacles : piétons, véhicules motorisés ou pas et "autres types"...
  • des photos de feux tricolores permettant d'entraîner les logiciels de reconnaissance des feux,
  • des données d'environnement permettant d'entraîner ou de tester les briques de calcul de trajectoire ou de compréhension de l'environnement... 
Pour les tests un outil permet de sélectionner le scénario : tourner à droite à un carrefour, à gauche, changer de voie... Avec différents type d'obstacles et sans. L'objectif est, pour chaque scénario, de récupérer les éléments perçus en entrée et de ceux attendus en sortie du module à tester.

Enfin, des données de démonstration permettent de constater et d'analyser le comportement des différents modules existants. Par exemple le module de fusion des données des différents capteurs permet de comprendre comment fonctionne le logiciel correspondant et d'en débugger les nouvelles versions.

La plateforme propose, naturellement, aux utilisateurs d'enrichir la base avec des données qu'ils ont eux mêmes collectées, en précisant le capteur utilisé, le pays et si ces données ont été capturées en mode autonome ou non. Cette approche rappelle celle astucieusement proposée par Coma.ai. Si vous disposez d'un boîtier ODB sur votre véhicule et d'un simple téléphone mobile équipé de l'application Chffr (ou mieux du DashCam EON ) , vous pouvez enregistrer toutes vos données de conduite et la vidéo capturée par votre "DashCam". Coma.ai propose alors de les télécharger pour enrichir sa base de conduite ! Quel bénéfice pour vous ? l'avenir des voitures autonomes dépend de vous !

Un écosystème de partenaires

Une centaine de partenaires sont actuellement identifiés parmi lesquels : Bosch, Delphi et Continental, ou Intel, Miscrosoft et NVIDIA... Cet écosystème permet de proposer des réalisations très variées. On trouve notamment des vidéos de promotion pour des intégrationsdu système dans des camions (CIDI), des bus Golden Dragon...

Un fond d'investissement

Enfin, Baidu propose aux start-ups actives dans les domaines des capteurs, des données ou du software des offres de capital...

Réglementation et mobilité en débat aux Etats Unis

Le premier accident mortel impliquant un véhicule Uber en mode autonome et un piéton a eu lieu le 20 mars 2018. Quelques semaines après, les révélations concernant le traitement des données personnelles par Facebook et Cambridge Analytica ont conduit à l'audition de Mark Zuckerberg par le congrès américain. Ces deux événements ravivent le débat sur la réglementation et l'innovation aux USA en général et en Californie en particulier. 

Citylab titre "il est temps de réglementer la technologie des Smart Cities". Laura Bliss dénonce le "laissez faire" des autorités américaines plus préoccupées par la promotion des entreprises innovantes que par la protection des citoyens. Elle souligne les risques importants liés non seulement au traitement des données de mobilités mais aussi  à la sécurité physique des voyageurs.

Jeff Spross dans The Week du 8 mars, estime que les véhicules autonomes sont surfaits (overhyped). Il montre que les bénéfices liés à la diminution des embouteillages et de la pollution ne sont pas liés à l'automatisation des véhicules. L'automatisation qui rendrait les déplacements automobiles plus souples, moins chers et plus confortables, pourrait au contraire aggraver la congestion et la pollution. Les mesures réellement efficaces : augmentation du partage des véhicules (autonomes ou pas), l'électrification massive et développement des transport public demandent des décisions publiques difficiles à prendre ! The New York Times produit une belle infographie sur le même sujet intitulée Automated Vehicule Can't Save Cities avec à peu près le même argumentaire.

La décision publique c'est, d'ailleurs, explicitement le champs d'action de SideWalk Labs filiale d'Alphabet qui souhaite "accélérer l'innovation urbaine et être un phare pour les villes autour du monde" ("we’re creating a new type of place to accelerate urban innovation and serve as a beacon for cities around the world"). Elle est notamment active à Toronto où elle teste Replica un outil qui promets de mettre la données au service de la gouvernance, mais sur lequel peu d'informations sont disponibles pour le moment (seule une partie des principes de traitement est ouverte).

Les universitaires américains étudient aussi les liens entre innovation et réglementation. C'est le sujet de Is It Time for a Public Transit Renaissance? Navigating Travel Behavior, Technology, and Business Model Shifts in a Brave New WorldSusan Shaheen et Adam Cohen de ITSBerkeley y formulent quatre propositions pour les autorités de transport :
  • développer des partenariats public/privé, notamment pour développer l'offre de transport à la demande pour améliorer le rabattement et la diffusion à partir des lignes régulières et proposer des services moins coûteux à la place des lignes les moins fréquentées,
  • l'avènement des véhicules autonomes (sur le quel les auteurs ne partagent pas les doutes de Jeff Spross) devrait encore accélérer la tendance,
  • d'accélérer l'ouverture des données, de nouer des partenariats public/privé pour mieux les exploiter et même d'envisager d'obliger certains acteurs à fournir des données de reporting,
  • enfin, il rappelle que les services de transport doivent rester abordables et leur accès équitable.

Sur le même sujet et des mêmes auteurs, Shared Mobility Policy Briefs fait des propositions plus précises dans le cadre spécifique de l'Etat de Californie. L'état de Californie devrait, par exemple,  obtenir l'accès aux données des acteurs privés en contrepartie de l'utilisation de droits de passage dans l'espace public. Je copie ci dessous les recommandations relatives aux "applications mobiles et données impactant les transports" et vous encourage à lire le document en intégralité:


Maas : la feuille de route d'ATEC ITS France dans le cadre de Mobilité 3.0

Je profite de ce WE froid et humide pour revenir sur la Feuille de route Maas (pour Mobility as a service) de l'ATEC ITS France.
Ce document, que je vous engage à lire si vous êtes intéressé par la billettique et l'information multimodale, présente à la fois une vision de ce qu'est le "Maas" et les modalités possibles de son déploiement, des recommandations sur lesquelles je vais revenir, mais aussi un état des lieux intéressant. L'état des lieux porte notamment sur les technologies : billettiques et information multimodale dans un tableau synthétique intéressant proposé en annexe. 

L'état des lieux liste aussi les atouts et les caractéristiques nationales qui font obstacle à la mise en oeuvre de la vision... On y trouve notamment :

  1. "Une priorisation insuffisante des investissements publics sur les territoires à enjeux: les villes, communautés d’agglomérations et les métropoles déploient peu de solutions relevant de l’information ou de la billettique multimodale
  2. La multiplicité des acteurs, l’absence de chef de file, qui pénalisent la gouvernance, complexifient les projets, surenchérissent les couts et les délais
  3. La nécessité de déployer des solutions pour le plus grands nombre et non uniquement pour des catégories sociales aisées des centres urbains. 
  4. La non intégration de la voiture dans le dispositif de mobilité, qui concentre 5 des 16 freins identifiés avec le plus haut score d’importance sur le manque de coopération entre acteurs de l’automobile et de la mobilité. 
  5. Le manque de données (en particulier routières) et la qualité des données permettant de construire des services de haut niveau."
Les recommandations sont priorisées et réparties en 4 axes : Connaître, Innover, Déployer, Organiser... Les plus prioritaires sont : 

Quatre propositions relatives à l'intégration de la voiture  : 
  • "Le développement des incitatifs de covoiturage (tarifaires, temps de parcours : voies réservées, ouverture des couloirs bus, ...) et les dispositifs de contrôle."
  • "Le déploiement de moyens pour disposer de la données temps réel de trafic routier (boucles, FCD, ...) L’évolution de la tarification de la mobilité au niveau des bassins de vie afin de favoriser la mobilité durable là où des alternatives existent (tarification centrée sur l’usage, simplification des tarifications, intégration de la voiture en favorisant le covoiturage, ...). "
  • "Permettre aux AOMD de mettre en place des péages urbains, ou une tarification de la voiture intégrée aux autres mobilités. "
  • "Le développement de projets de covoiturage périurbain rassemblant agglomérations et des acteurs de la filière automobile intégré à la billettique multimodale. "
Puis des actions relatives aux données de mobilités :
  • "Le passage aux actes sur l’ouverture des données publiques, l’accès à de nouvelles données publiques et la disponibilité des données privées en mode partenarial, en veillant cependant à l’équité concurrentielle",
  • "La création de plateformes territoriales, au bon niveau selon les situations permettant de rassembler l’ensemble des données en un seul point, ce qui facilite la création de services totalement multimodaux." 
Enfin, des actions liées à la gouvernance :
  •  "avoir un chef de file sur la mobilité ce qui est clef pour faciliter le déploiement du MaaS. Plusieurs pistes sont à explorer..."
  • "Déployer des structures de droit privées pilotées par les AOMD et des partenariats pour porter l‘information multimodale et la billettique multimodale sur les territoires." 
  • "Mettre en place un groupe Filière Automobile / AOMD / Opérateurs de transports collectifs / Opérateurs de covoiturage, sur le partage des données GPS / géolocalisées des voitures, la complémentarité covoiturage/TC, le montage de projets afférents." 
et des actions liées aux besoins en financements et à la capitalisation des expériences.

Ce dernier paragraphe porte une conviction d'ordre architecturales, je cite : "Il s’agit clairement de se focaliser sur les innovation et investissements relatifs aux architectures MaaS dites en back office, et donc à exclure du champs de ces financements les systèmes de billettiques dites media centric"
Je ne doute pas que cette phrase puisse être âprement discutée et même contestée par les partisans des systèmes "media centric", et j'en connais... 
Les tenants de ce débat opposent les systèmes de billettiques dans lesquelles le voyageurs porte un dispositif d'authentification, la vérification de ses droits (ou le calcul du sa redevance) se faisant en central (en "back office") à ceux qui considèrent que le voyageur doit porter ses droits localement.... Le premier défendent l'ABT pour Account Based Ticketing.
Pour ma part,je ne souhaite pas prendre position dans ce débat que je trouve vain comme la plupart des convictions générales en matière d'architecture technique. Je crois qu'une architecture technique doit répondre à des besoins et des contraintes spécifiques dans le cadre d'un projet donné.

Au final, un document synthétique et intéressant qui va m'inciter à suivre plus régulièrement les productions de l'ATEC ITS.