Une voiture de course est un environnement exigeant, soumis à des contraintes de vitesse, de chaleur et de télémétrie. Comment un agent sur l'appareil peut-il aider à traiter les données d'un véhicule en temps réel pour des applications sportives et d'ingénierie ?
Cette session technique explore une architecture hybride expérimentale combinant du matériel de périphérie et des agents cloud. Nous allons vous présenter une démonstration de faisabilité de recherche utilisant un Raspberry Pi pour diffuser la télémétrie du bus CAN, un téléphone Pixel exécutant un agent conversationnel sur l'appareil optimisé par ML Kit et Gemini Nano, et une connexion cloud agent-to-agent (A2A) pour les workflows d'après-course.
Transcription
Bonjour !
Je m'appelle Alastair et je suis ravi de vous parler aujourd'hui d'un projet que nous avons entrepris l'année dernière avec la Formule E.
Oli est avec nous aujourd'hui pour nous parler un peu de ce que nous avons fait ensemble.
Je travaille dans le bureau du directeur de la technologie de Google Cloud. Nous cherchons souvent à repousser les limites de ce qui est possible aujourd'hui sur mobile et dans le cloud, et à voir comment ils peuvent fonctionner ensemble.
Je vais vous montrer une courte vidéo qui vous donnera un aperçu de ce que nous avons fait.
La voiture Gen 4 est un monstre de course de 600 kW.
Alimentation entièrement électrique, transmission intégrale permanente.
Je dirais qu'il est sacrément rapide.
Pourrions-nous utiliser un agent sur un téléphone Pixel connecté aux données de télémétrie provenant de la voiture ?
En montant la colline de Goodwood, le pilote pourra parler à la voiture.
Plutôt pratique !
Hey Gemma, quel est l'état de mes pneus ?
La pression des pneus semble bonne, environ 1,4 bar.
Un téléphone est branché directement sur l'ECU, qui lit de nombreux points de données sur ce que je fais en tant que pilote.
C'est la première fois que cela se produit dans une voiture de course.
Je pense qu'il n'y a pas de meilleur endroit pour le présenter.
Hey Gemma, on est prêts ?
Utilisable n'importe quand
Nous avons donc vu un projet dans lequel nous voulions essayer d'intégrer un agent copilote dans le cockpit avec le pilote.
En fait, nous essayons de repousser les limites de ce qu'il est possible de faire avec des agents en périphérie, car il s'agit d'un excellent exemple de défi très difficile.
Les défis auxquels vous êtes confronté dans une voiture de course sont évidemment la chaleur élevée.
Les voitures de course sont connues pour chauffer, et c'est l'un des plus grands défis.
Connectivité irrégulière.
Nous faisons cela au Goodwood Festival of Speed, où des centaines de milliers de fans de sport automobile se rassemblent pour regarder des voitures faire une course de côte.
Et comme vous pouvez l'imaginer, quand des centaines de milliers de personnes se trouvent dans un champ, la connectivité peut être assez difficile.
et le Bluetooth.
Par exemple, cette voiture est en quelque sorte une cage de Faraday. Vous pouvez donc imaginer les difficultés que nous rencontrons pour nous connecter au casque du pilote.
Enfin, les exigences de faible latence.
Ce pilote roule à plus de 200 km/h. Il est donc très important que les réponses de son agent copilote soient très rapides et concises.
Et fondamentalement, nous nous intéressons de près à ce sujet, car nous pensons que les agents vont devenir omniprésents.
Nous commençons déjà à le constater.
Ils ne sont plus seulement dans nos ordinateurs.
Ils sont dans nos téléphones, nos montres, nos lunettes, nos maisons connectées et même nos voitures.
Nous voulions donc voir ce que nous pouvions accomplir dans un scénario aussi difficile.
Lorsque nous réfléchissions à la façon de créer ce système, nous nous sommes demandé si nous devions créer un petit micro-ordinateur avec un petit accélérateur pour y intégrer un modèle.
Nous avons soudainement réalisé que tous les ingrédients dont nous avions besoin existaient déjà, et qu'il s'agissait d'Android.
Android est l'hôte idéal pour cela, car vous disposez d'ADK, notre Agent Developer Kit.
Cette bibliothèque très pratique vous permet de créer des agents directement dans votre application.
Il y a des milliards d'utilisateurs, et, vous savez, différents facteurs de forme sur lesquels nous pouvons l'exécuter très facilement. Il est donc très facile de tester cela et de distribuer le code lui-même.
Les outils pour les développeurs vous permettent de déboguer, d'essayer différentes choses et de trouver ce qui ne va pas.
L'IA sur l'appareil : les téléphones Google Pixel sont désormais équipés d'un TPU intégré, optimisé pour le modèle sur l'appareil qui se trouve directement dans le téléphone. Il est ainsi très facile d'accéder à un modèle très puissant à l'aide d'API telles que ML Kit.
Nous proposons également des API entièrement hors connexion, comme la synthèse vocale et la reconnaissance vocale, qui vous permettent de créer des expériences conversationnelles très performantes.
Et enfin, bien sûr, la connectivité.
Les téléphones sont conçus pour la connectivité, que ce soit via les réseaux mobiles, le Wi-Fi ou d'autres moyens.
Cependant, l'un des défis est que les agents en périphérie ne peuvent pas tout faire. Comment pourraient-ils collaborer avec des agents dans le cloud ?
Et si la solution était hybride ?
Et si un agent résidant sur un téléphone pouvait parler directement à un agent dans le cloud pour effectuer des actions plus complexes ?
Par exemple, imaginons que le pilote veuille connaître sa position dans la course.
La voiture elle-même ne saura pas quelle est sa position dans la course, mais un agent dans le cloud le saura peut-être.
Nous avons également un protocole appelé "agent-to-agent", qui vous permet de créer des agents en périphérie et dans le cloud, et de les faire communiquer entre eux pour effectuer des actions plus complexes.
Alors, comment l'avons-nous conçu ?
Je vais donc vous présenter les ingrédients de ce système.
Commençons par le faisceau.
Ici, le harnais est une application Android exécutant Agent Development Kit pour Android.
La deuxième partie est un modèle.
Vous avez besoin d'un modèle pour l'alimenter. Pour notre part, nous avons utilisé Gemini Nano via ML Kit, un modèle sur l'appareil très puissant et à portée de main.
Ensuite, les données.
Oli va en parler dans un instant, mais vous avez les données provenant de la voiture, et potentiellement aussi la reconnaissance vocale du conducteur.
Enfin, vous avez également les actions que l'agent peut effectuer.
Il peut s'agir de la synthèse vocale pour pouvoir répondre au conducteur et lui poser des questions complémentaires ou lui donner les informations requises, ou, comme mentionné précédemment, de la communication d'agent à agent avec un agent dans le cloud pour effectuer certaines des actions les plus complexes.
J'aimerais maintenant inviter Oli à monter sur scène pour nous expliquer comment nous avons procédé avec la Formule E.
Merci, Alastair.
Maintenant que nous avons nos ingrédients, passons à la partie la plus difficile : comment intégrer un agent IA dans une voiture de Formule E ?
Tout commence ici, au niveau de l'unité de contrôle du véhicule (VCU).
Désormais, chaque capteur et chaque composant de la voiture lui transmettent des informations via un bus CAN.
La voiture génère des milliers de points de télémétrie par seconde, comme la vitesse, l'accélération, l'accélérateur, le freinage, etc.
Pour lire cette télémétrie, nous avons décidé de brancher un Raspberry Pi directement sur le VCU de la voiture via cette connexion CAN.
Le Raspberry Pi effectue différentes actions.
Tout d'abord, il décode les signaux bruts, les transforme et les sous-échantillonne à environ 10 Hz, ce qui fournit de nombreuses informations pour un copilote.
Le Raspberry Pi publie ensuite ces données affinées via MQTT sur un Pixel 10 Pro installé dans l'habitacle de la voiture.
Il s'agit d'une entrée que l'application hébergeant notre application d'agent peut accepter.
La deuxième est la reconnaissance vocale Android.
Ainsi, lorsque le conducteur parle, l'application convertit l'entrée en texte, et Gemini Nano est capable de raisonner sur ces deux entrées.
L'agent peut alors prendre deux décisions : d'abord, il peut utiliser le moteur de synthèse vocale d'Android pour répondre au conducteur.
Deuxièmement, comme Alastair l'a mentionné précédemment, il peut communiquer avec l'agent cloud via le protocole A2A.
Le flux de l'agent est assez simple : dites le mot clé, dans ce cas "Hey, Gemma", posez une question et obtenez une réponse.
L'agent reste à l'écoute pendant environ cinq secondes après avoir répondu, ce qui vous permet de poser une question complémentaire sans avoir à recommencer, comme si vous parliez à un véritable ingénieur de course.
L'application est également un agent multitour, ce qui signifie qu'elle peut accéder à l'historique des conversations pour être plus conversationnelle.
Vous vous attendez peut-être à ce que le code soit un peu compliqué, n'est-ce pas ?
En fait, c'est très simple.
Les premières lignes appellent onDeviceModel à l'aide de ML Kit et l'encapsulent en tant que Gemini Nano.
val generativeModel: GenerativeModel = Generation.getClient()
val onDeviceModel = GenaiPrompt.create(
generativeModel = generativeModel,
name = "gemini-nano",
)
val agent = LlmAgent(
name = "race_engineer",
model = onDeviceModel,
staticInstruction = /* System prompt */,
instruction = Instruction {
/* Dynamic context */
},
tools = listOf(
/* Custom tools */
)
)Ensuite, nous définissons notre agent avec ADK.
Donnez-lui un nom et deux types d'instructions : la première est l'instruction statique, qui définit sa personnalité et son identité.
Cela peut inclure des éléments tels que la façon dont il répond au conducteur et des informations sur le circuit.
La deuxième est l'instruction dynamique.
Ce résumé est généré à chaque requête avec les dernières données de télémétrie. L'agent sait donc toujours ce que fait le pilote à tout moment.
Comme indiqué précédemment, il inclut également l'historique de la conversation en cours.
En plus de cela, nous définissons également des outils, par exemple, pour lui permettre de communiquer avec les données de session précédentes, avec l'agent cloud et avec le conducteur à l'aide de la synthèse vocale.
Voyons maintenant une démonstration rapide de l'agent en action sur nos simulateurs dans les bureaux de la Formule E.
Hey Gemma, est-ce que je braque trop brusquement ?
Douce et mesurée.
Le braquage maximal était de 48 degrés, et vous tourniez le volant de 11 degrés par seconde en moyenne.
Hey Gemma, quelle est ma force G maximale ?
La force G maximale était de 2, 2 G dans les virages.
Hey Gemma, comment s'est passée ma course ?
Belle course, Dan.
Vitesse maximale de 306 km/h, avec une moyenne de 186 km/h sur 35 secondes.
Vous avez roulé à fond 58 % du temps et atteint un pic de 2, 2 G.
Voilà, c'est fini.
C'est Gemini Nano sur un téléphone qui parle à un conducteur et répond à ses questions en temps réel.
Un simulateur est une chose, une voiture de Formule E en est une autre.
Alors, comment avons-nous procédé ?
Nous avons d'abord dû nous rendre chez Spark Racing Technology à Paris, où nos voitures sont fabriquées.
Ici, à gauche, c'est moi en train de connecter le Raspberry Pi au VCU de la voiture de Formule E.
Tout ce que nous avons créé jusqu'à présent s'est exécuté sur des données émulées et a été rejoué à partir d'une session de test. Nous ne savions donc pas vraiment si cela fonctionnerait avec des données réelles.
Nous l'avons donc branché, allumé, attendu, attendu encore un peu, et enfin, la télémétrie a commencé à s'afficher sur l'appareil, prouvant que les données circulaient dans le système comme prévu.
À droite, vous pouvez voir le système terminé, et vous pouvez voir que le téléphone est en fait intégré au cockpit, juste à côté de l'endroit où le pilote sera assis.
Nous étions donc prêts pour Goodwood.
Alors, que s'est-il passé ce jour-là ?
Vous vous souvenez des quatre défis dont Alastair a parlé plus tôt ?
Goodwood en a vraiment testé deux.
Le premier était la chaleur.
En Grande-Bretagne, nous nous préparons généralement à tous les temps, sauf au soleil.
Et, comme par hasard, nous avons eu droit à l'une des semaines les plus chaudes jamais enregistrées, en plein milieu d'une canicule.
C'était le moment idéal pour installer un ordinateur dans une voiture de Formule E.
Mais il y a un hic.
Le téléphone était en fait en bon état.
Android n'a pas vraiment souffert.
Il s'avère que c'est le Raspberry Pi qui a rencontré le plus de difficultés.
Comme nous ne pouvions pas le brancher directement sur la voiture, nous avons dû utiliser un onduleur, qui ressemble à un ensemble de batteries collées sous le Pi.
Heureusement, nous avons réussi à résoudre ce problème en rechargeant la batterie de temps en temps au cours de la journée. Sans cela, la voiture n'aurait probablement pas pu monter cette côte sans agent IA.
Ensuite, le Bluetooth.
À ce stade, nous n'avions jamais testé le casque du pilote, qui se connecte à l'application via le Bluetooth.
Et cela s'est avéré un peu difficile.
Pour tester cela, nous nous sommes assis sur l'herbe, et on dirait que nous passons un très bon moment, n'est-ce pas ?
Nous avons sorti nos ordinateurs portables et nous discutons tranquillement.
En réalité, c'était probablement l'une des périodes les plus stressantes de ma carrière jusqu'à présent.
Nous essayions désespérément de faire fonctionner ce code et de connecter le casque Bluetooth à l'application avant que la voiture ne monte la colline l'après-midi.
Mais grâce à des correctifs de dernière minute et aux formidables outils de débogage d'Android, nous avons réussi à résoudre le problème juste à temps, et la voiture a gravi la colline avec l'agent IA qui fonctionnait parfaitement.
Je vais maintenant laisser la parole à Alastair, qui va nous parler un peu plus des enseignements tirés du projet.
Merci.
Merci, Oli.
Alors, qu'avons-nous appris de ce projet ?
Tout d'abord, Android est un hôte idéal pour vos agents.
Je vous encourage vivement à utiliser la polyvalence d'Android, les API disponibles, les modèles sur l'appareil et l'ADK.
Essayez-les, car vous serez surpris de la puissance des expériences que vous pouvez obtenir avec un outil aussi simple.
L'enfer de l'intégration existe toujours.
La plupart des personnes présentes dans cette salle ont probablement déjà vécu cela à un moment ou à un autre de leur carrière.
Vous créez tous les sous-composants séparément, puis, lorsque vous les assemblez, quelque chose ne fonctionne pas tout à fait.
Et le casque du pilote était exactement comme ça.
Heureusement, nous avons pu résoudre le problème le jour même, ce qui prouve que les tests sont vraiment essentiels.
Enfin, Gemini Nano.
Gemini Nano a été d'une grande aide.
C'est un modèle très efficace, qui s'exécute très rapidement sur votre appareil et peut effectuer des tâches très complexes, mais pas immédiatement.
Il y a une vraie réflexion derrière tout ça.
Vous devez utiliser le prompt engineering.
Vous devez le tester.
Vous devez réfléchir à la manière dont vous souhaitez fournir l'instruction dynamique par rapport à l'instruction statique.
Vous devez réfléchir aux outils que vous allez lui fournir et à la meilleure façon de lui donner des instructions.
Mais avec les bons tests et évaluations, vous pouvez tirer le meilleur parti d'un modèle comme Gemini Nano directement sur l'appareil.
Merci beaucoup à toutes et à tous.
Nous serons sur le stand plus tard, alors n'hésitez pas à venir nous poser des questions.
val generativeModel: GenerativeModel = Generation.getClient()
val onDeviceModel = GenaiPrompt.create(
generativeModel = generativeModel,
name = "gemini-nano",
)
val agent = LlmAgent(
name = "race_engineer",
model = onDeviceModel,
staticInstruction = /* System prompt */,
instruction = Instruction {
/* Dynamic context */
},
tools = listOf(
/* Custom tools */
)
)