Bagel 2.0 veut réduire les données de robots dès l’edge

Illustration éditoriale de données ROS filtrées autour d’un événement robotique
Bagel 2.0 veut aider les équipes robotique à interroger et réduire leurs journaux de données physiques.

Bagel 2.0 veut simplifier un problème très concret de la robotique : transformer des journaux ROS, drones ou IoT en réponses exploitables, sans devoir écrire un script différent à chaque incident. L’annonce publiée mardi matin sur Open Robotics Discourse présente une version open source centrée sur l’interrogation en langage naturel et la réduction de données au plus près des machines.

Le projet, développé par Extelligence AI, se connecte à des sources comme ROS 1, ROS 2, MCAP, PX4, ArduPilot, Betaflight, des captures CAN ou encore MQTT. L’utilisateur pose une question en langage courant, mais Bagel ne se contente pas d’une réponse générée par un modèle : il écrit les messages dans Apache Arrow, exécute des requêtes DuckDB et affiche la requête utilisée pour que le résultat puisse être audité.

Réduire les données avant de les déplacer

La nouveauté mise en avant dans Bagel 2.0 est la pipeline de réduction. Une consigne comme « conserver dix secondes autour de chaque forte décélération » devient un détecteur, prévisualisé avant écriture, puis appliqué à un sac ROS, à un lot de fichiers ou directement en périphérie. Le projet affirme que les fenêtres conservées restent identiques au niveau des messages, tandis que les données hors événement sont écartées.

Pour les équipes robotique, cette logique répond à un irritant connu. Les robots de terrain produisent beaucoup de données, mais les moments intéressants sont rares : freinage brutal, perte de localisation, surchauffe d’un capteur, choc, alerte de batterie ou anomalie dans un topic de diagnostic. Enregistrer tout, puis transférer tout, finit par coûter cher en stockage, en réseau et en temps d’analyse.

Bagel se positionne donc comme une couche de dialogue et de tri. Il peut résumer un bag, extraire des erreurs de logs ROS, chercher une corrélation entre courant et tension, préparer des fenêtres pour PlotJuggler, Rerun, Lichtblick ou LeRobot, et exécuter la même pipeline sur plusieurs fichiers.

Un MCP pour données physiques

Le projet insiste aussi sur son intégration avec les clients MCP et les environnements de développement modernes. Le dépôt mentionne Claude Code, Gemini, Cursor, Codex et Copilot, ainsi qu’un fonctionnement local via Ollama pour garder données et modèle sur la machine. Les environnements Docker couvrent plusieurs distributions ROS, notamment Kilted, Jazzy, Iron, Humble et Noetic.

Cette compatibilité ne suffit pas à en faire une solution de production prête pour toutes les flottes. Les équipes devront vérifier les formats, les performances sur de gros volumes, les droits d’accès aux données et la robustesse des détecteurs. Mais le choix de requêtes SQL auditables est un signal positif : dans la robotique, une réponse plausible mais fausse peut coûter beaucoup plus cher qu’un simple bug d’interface.

Notre analyse

Bagel 2.0 n’est pas un nouveau robot et ne remplace pas les outils historiques comme ros2 bag, PlotJuggler ou les scripts Python. Son intérêt est d’orchestrer ces analyses autour de questions opérationnelles : quel événement s’est produit, à quel moment, sur quel topic et quelles secondes faut-il conserver pour comprendre le problème.

Si la promesse tient sur des données de terrain réelles, ce type d’outil peut devenir utile dans les flottes où l’enjeu n’est plus de démontrer un robot, mais de maintenir des dizaines ou centaines de machines. La robotique de production a besoin d’outils qui réduisent le bruit, gardent une trace vérifiable des calculs et rapprochent l’analyse des incidents du bord réseau.

Le briefing RoboActu

L’essentiel de la robotique, une fois par semaine.

Une sélection courte des annonces, usages et robots à suivre.

Continuer sur ce sujet

Comparer les robots