L'IA physique va transformer les industries du monde réel, mais la robotique manque encore d'une couche de données unifiée nécessaire pour itérer à la vitesse qu'exige l'IA moderne. Le défi principal est que l'apprentissage robotique opère sur des données physiques : des flux multimodaux et multi-débits liés au temps, à l'espace et à l'incarnation. L'infrastructure existante, largement construite autour des données web, peine à gérer ces propriétés.
Chez @rerundotio, nous construisons une couche de données unifiée pour les données physiques afin d'aider les équipes à entraîner et déployer l'intelligence pour le monde réel.
La plus grande version de Rerun à ce jour
Rerun est surtout connu pour la visualisation de données temporelles multimodales. Depuis un an et demi, nous construisons discrètement les autres éléments d'une couche de données unifiée pour soutenir l'ensemble du parcours, de la collecte à l'entraînement. Avec la version 0.32 du SDK Rerun, ces capacités arrivent en open source !
Il s'agit de la plus grande version depuis que Rerun a été initialement open sourcé il y a trois ans, et elle représente une énorme expansion des types de travaux que vous pouvez réaliser avec Rerun.
Nous stabilisons le format de fichier et ajoutons un nouvel ensemble d'API de lecture et d'écriture de bas niveau pour les fichiers. Nous ajoutons une nouvelle API pour manipuler les blocs de données Rerun, conçue pour le traitement et la normalisation des données robotiques réelles. Nous élargissons notre prise en charge des messages MCAP et ROS 2 pour améliorer l'expérience prête à l'emploi. Nous ajoutons une nouvelle interface utilisateur de révision de jeux de données pour accélérer considérablement la révision des ensembles d'entraînement. Le serveur de catalogue open source indexe désormais les fichiers .rrd sur le disque, permettant à vous ou à votre agent d'écrire des requêtes génériques sur des répertoires d'enregistrements robotiques. Construit sur cette même base, nous publions également un chargeur de données PyTorch pour vous permettre d'entraîner des modèles robotiques directement sur des fichiers .rrd, sans avoir à exporter vers un format spécifique à l'entraînement.
L'écosystème robotique manquait d'un cadre unifié suffisamment flexible pour soutenir l'ensemble du cycle de vie des données d'apprentissage robotique. Avec la version 0.32, cette fondation émerge désormais.
En plus de cette énorme version open source, nous annonçons également Rerun Hub, notre catalogue de données et moteur de stockage commercial. Rerun Hub est désormais en aperçu privé et étend le SDK Rerun aux ensembles de données sauvegardés par le stockage d'objets. Il fournit un catalogue partagé et une couche d'accès pour transformer, interroger, visualiser et diffuser des données robotiques à une échelle beaucoup plus grande, tout en préservant le même modèle de données et les mêmes API.
Utilisez Rerun Hub si votre ambition est de faire évoluer les données au-delà de ce qui tient sur votre machine locale – tout en allant vite ! Si vous êtes une équipe qui construit un produit autour de l'apprentissage robotique et que vous réfléchissez à votre couche de données, contactez-nous.
Le reste de cet article comporte deux parties. D'abord, une introduction à l'architecture de données que nous pensons nécessaire à l'IA physique pour passer à l'échelle. Ensuite, une visite guidée des nouvelles capacités du SDK Rerun 0.32 qui mettent cette architecture en pratique.
L'apprentissage robotique a besoin d'une couche de données spécialement conçue pour les données physiques
Comme indiqué dans \The Data Layer Tax for Robot Learning\, une grande partie des frictions qui ralentissent les progrès de l'IA physique provient de la tentative de faire passer les données physiques par une infrastructure conçue pour les charges de travail logicielles et analytiques traditionnelles. Ce dont on a besoin, c'est d'une couche de données construite pour des données multi-débits et multimodales, qui prenne en charge tout ce dont vous avez besoin pour itérer sur l'intelligence robotique, de la collecte à l'entraînement et au déploiement.
Les agents de codage signifient que les utilisateurs ont besoin d'un contrôle total sur la couche de calcul et d'application
Pour servir l'ensemble du flux de travail de collecte, normalisation, post-traitement, curation et entraînement, les équipes ont besoin d'une variété d'outils et de tâches de calcul. Ces outils et tâches peuvent, par exemple, encoder les manières spécifiques dont une équipe opère ou les techniques qu'elle utilise pour piloter la qualité des données à grande échelle, ce qui en fait un domaine de différenciation clé que les équipes doivent maîtriser.
Les agents de codage rendent de plus en plus possible pour les équipes de concevoir ces outils et tâches de calcul exactement comme elles le souhaitent, à condition d'avoir un contrôle au niveau du code. Pour cette raison, très peu d'équipes accepteront de ne pas avoir ce contrôle. C'est pourquoi le SDK Rerun est entièrement open source et conçu comme un cadre que vous pouvez utiliser pour construire, plutôt qu'une plateforme SaaS cloisonnée. Même la visionneuse est conçue comme une bibliothèque pour que vous ne soyez jamais bloqué. Rerun a toujours été axé sur le code en premier et nous avons redoublé d'efforts pour le rendre encore plus facile à utiliser pour les agents. Cela inclut même des travaux à venir sur le rendu entièrement sans tête et la navigation dans la visionneuse pour aider les agents à voir les données physiques comme le feraient les humains.
La plupart des équipes construisent déjà des applications uniques et des scripts de traitement personnalisés adaptés à leurs propres flux de travail. Sans construire sur une base solide, vous vous retrouvez avec des éléments verticaux difficiles à raisonner et qui ne se composent pas bien, ce qui limite les gains de productivité.
La couche de données doit gérer les aspects difficiles de l'utilisation de données physiques à grande échelle
Les capacités de base nécessaires pour servir l'ensemble du parcours des données, de la collecte au modèle, sont la visualisation, l'interrogation analytique, la transformation et l'entraînement. Toutes ces capacités doivent traiter des données multi-débits et multimodales qui peuvent porter des sémantiques robotiques comme les relations 3D ou la forme. Pour éviter les bugs et les données incohérentes, vous voulez traiter les subtilités de ce type de données de manière cohérente partout où elles sont utilisées. Par exemple, l'alignement temporel et les transformations 3D doivent se comporter de manière cohérente entre le prétraitement, l'interrogation, la visualisation et la révision des ensembles de données.
Pour faciliter l'itération à la fois sur la boucle données-expérience et sur les outils qui l'alimentent, vous voulez construire sur une seule couche de données unifiée qui rend les transferts triviaux et les applications au-dessus simples. Cela signifie que la couche de données doit être suffisamment flexible pour répondre aux exigences de toutes les capacités de base des applications et du calcul. Par exemple, la visualisation et le calcul nécessitent tous deux un accès aléatoire rapide aux séries temporelles multimodales, tandis que les requêtes analytiques nécessitent des analyses de colonnes efficaces, et que le calcul de post-traitement à grande échelle (CPU) et l'entraînement (GPU) nécessitent tous deux un streaming de données parallèle à large bande passante.
Les données physiques se comportent fondamentalement différemment des données web et commerciales, ce qui signifie qu'elles bénéficient de différentes abstractions de stockage et d'interrogation.
L'unité de stockage de base pour les données physiques est un bloc de colonnes
Les données physiques ont deux caractéristiques distinctives :
La première est qu'elles sont multi-débits : différents capteurs enregistrent des données à des fréquences radicalement différentes. Le GPS peut être à 1-10 Hz, les caméras à 10-30 Hz, les angles d'articulation à 100-200 Hz et l'IMU à 1 kHz. En post-traitement, vous pouvez calculer des embeddings sémantiques pour chaque 10e image de la caméra ou des descriptions de scène au début et à la fin de chaque épisode.
La seconde est qu'elles sont multimodales : différents capteurs enregistrent des données de tailles radicalement différentes. L'IMU et le GPS n'ont besoin que d'une poignée d'octets pour encoder quelques nombres, tandis qu'une caméra RVB peut utiliser plusieurs Mo pour chaque image.
Si vous deviez stocker un enregistrement robotique dans une table où une ligne représente un horodatage et une colonne représente un flux de données, l'aspect multi-débits rendrait généralement cette table très creuse ; pour une ligne donnée, la plupart des colonnes sont probablement vides. L'aspect multimodal des données conduit à un déséquilibre de mémoire important car une seule ligne peut contenir des cellules dont la taille diffère de plusieurs ordres de grandeur. L'infrastructure de données tabulaires existante gère très mal cette combinaison.
Les données multi-débits et multimodales doivent être stockées dans des blocs qui contiennent chacun des sous-ensembles des lignes et des colonnes d'un ensemble de données. La capacité, par exemple, de placer un million d'échantillons IMU dans un bloc et seulement quelques paquets vidéo dans un autre bloc vous permet de résoudre à la fois les problèmes de creux et de déséquilibre de mémoire.
Au sein du bloc, le stockage orienté colonnes optimise pour une meilleure compression et des requêtes d'analyse de colonnes, tandis que le stockage orienté lignes optimise pour des écritures simples.
Chez Rerun, nous croyons que les blocs de colonnes représentent le meilleur compromis pour les systèmes de données d'apprentissage robotique, et nous avons standardisé notre architecture autour d'eux comme abstraction de stockage de base.
Le format de fichier .rrd de Rerun est construit autour de blocs de colonnes
Le format de fichier natif de Rerun, .rrd, est la représentation sur disque de l'abstraction de bloc de colonnes. En interne, chaque bloc de colonnes est encodé comme un lot d'enregistrements Apache Arrow, accompagné de métadonnées sémantiques décrivant comment les données doivent être interprétées. Apache Arrow est la norme industrielle pour la science des données, et l'utilisation d'Arrow signifie que nous avons un chemin rapide sans copie vers DataFusion, Pandas et Polars.
Les métadonnées dans chaque bloc contiennent des informations sémantiques sur la façon d'interpréter les données (« ceci est un capteur IMU, ceci est un GPS, … ») afin qu'elles puissent être transportées à travers les pipelines de traitement et toujours être automatiquement interprétées et visualisées.
Les blocs de colonnes encodés sont enveloppés dans des messages protobuf et concaténés pour former un fichier .rrd. Un pied de page à la fin du fichier pointe vers un index, permettant un accès aléatoire rapide à des blocs individuels sans avoir à analyser l'ensemble du fichier.
Comparaisons avec d'autres formats
Apache Parquet est un format sur disque en colonnes, couramment utilisé avec Arrow. Il organise ses données en groupes de lignes, mais contrairement aux blocs dans .rrd, ces groupes ne peuvent pas se chevaucher : chaque groupe de lignes contient toutes les colonnes sur une plage dense de lignes. Cela le rend inadapté aux données robotiques multi-débits et multimodales. Vous pouvez ajouter de nouvelles lignes, mais vous ne pouvez pas ajouter de nouvelles colonnes (pas d'évolution de schéma).
MCAP est un format pour enregistrer des logs robotiques sur votre robot. Il est conçu pour être rapide et flexible à écrire, avec une forte compatibilité ROS. Cependant, c'est essentiellement un format de conteneur de messages opaques (encodés avec JSON, protobuf, CBOR, etc.) et non optimisé pour les requêtes analytiques en colonnes. Les grandes analyses et les jointures sont également lentes, car vous devez décoder chaque message.
Lance est un nouveau format, explicitement construit pour les données multimodales et l'accès aléatoire (ce qui est extrêmement important pour l'entraînement). Contrairement à Parquet, il prend en charge l'évolution du schéma. Cependant, un ensemble de données Lance reste une pile verticale de fragments alignés sur les lignes, donc les flux multi-débits gonfleront avec des valeurs nulles.
NCore est un nouveau format de Nvidia, construit pour la reconstruction neuronale. Le multi-débit est pris en charge nativement via des horodatages par composant, et l'alignement spatial via un graphe de poses. Cependant, le schéma est fermé (composants de capteurs canoniques, pas de données utilisateur arbitraires), il est basé sur Zarr plutôt que natif Arrow, et il n'est pas conçu pour servir un moteur de requête SQL / dataframe générique.
Chaque fonctionnalité dont votre équipe a besoin et qu'un format de fichier ne fournit pas signifie un pipeline supplémentaire à synchroniser et des outils supplémentaires à apprendre pour que votre équipe réussisse. Le format de Rerun est la seule option qui peut servir tous les cas d'utilisation nécessaires pour transformer les enregistrements robotiques en intelligence. Il vous permet de conserver les données aux horodatages d'origine, tout en étant capable d'interroger et de visualiser à partir de la même source de données, et de diffuser vers l'entraînement. Il a suffisamment de structure pour construire des systèmes de données unifiés par-dessus, mais est suffisamment flexible pour optimiser différents modèles de lecture et d'écriture.
Une couche d'indexation, de schéma et de métadonnées au-dessus des blocs de colonnes simplifie l'utilisation des données physiques à grande échelle
Analyser tous les blocs d'un ensemble de données pour analyser un seul signal passe mal à l'échelle, même pour de petits ensembles de données. Pour les utiliser efficacement, vous avez besoin d'une couche de métadonnées et d'indexation qui peut aider à trouver les bons blocs pour toute requête. Cela ressemble beaucoup au modèle classique du lac de données (data lakehouse). Dans notre cas, un seul ensemble de données ou enregistrement est composé de blocs hétérogènes qui ne partagent pas le même schéma. Les outils de traitement de données classiques sont conçus pour traiter des tables avec un schéma uniforme. Une couche d'indexation et de métadonnées de type lakehouse pour les données physiques doit donc également suivre ces schémas individuels afin de pouvoir matérialiser des schémas fusionnés de n'importe quel flux à la volée, permettant ainsi aux outils de données classiques de fonctionner avec. Par exemple, si vous mettez à niveau votre IMU vers un modèle qui publie des données de champ magnétique dans ses messages, cet ajout est compatible avec votre ancien IMU qui ne contenait pas ce champ ; pas besoin de réécrire les données historiques pour la compatibilité.
Les blocs de colonnes associés à une indexation efficace vous permettent de récupérer exactement les données dont vous avez besoin sans payer de pénalité pour les flux non liés stockés à côté. Vous n'avez pas à choisir entre rendre les opérations courantes rapides et être capable de traquer les bugs de longue traîne parce que vous avez exporté les données courantes vers un entrepôt séparé.
En plus des avantages en termes de performances, cette couche nous permet d'abstraire les fichiers et de présenter une API unifiée pour tous les utilisateurs de données physiques dans les couches supérieures. Souvent, les données robotiques sont stockées dans un fichier et l'étalonnage dans un autre ; abstraire ces détails d'implémentation est une partie importante de la réduction des frictions liées aux données et de la simplification de la couche de calcul et d'application.
Le traitement et l'entraînement à grande échelle nécessitent un streaming sélectif directement depuis le stockage d'objets
Les ensembles de données d'apprentissage robotique peuvent déjà devenir très volumineux et le deviendront encore plus à mesure que les équipes suivront les lois de mise à l'échelle pour obtenir des modèles de plus en plus performants. Pour traiter cette échelle de données, vous devez souvent répartir le travail sur un grand nombre de CPU pour le post-traitement ou de GPU pour l'entraînement. Dans ces cas, il est important que le débit des données puisse évoluer avec les besoins de ce calcul.
Pour maximiser les performances et minimiser les coûts de sortie, vous voulez exécuter le calcul près des données. En même temps, le calcul GPU peut être difficile à obtenir, donc de nombreuses équipes finissent par louer dans différents endroits au fil du temps. Tous ces facteurs signifient que vous voulez pouvoir séparer le stockage des services qui gèrent l'indexation et les métadonnées.
Dans Rerun, les requêtes partent du SDK Rerun qui interroge ensuite Rerun Hub, qui est responsable de savoir quels blocs sont nécessaires pour résoudre la requête. Selon le paramétrage, le SDK demande soit les blocs via un proxy mis en cache dans Rerun Hub, soit des plages d'octets sur le stockage d'objets. Cela permet une API d'accès simplifiée, un streaming sélectif de blocs et la bande passante de streaming maximale du stockage d'objets sous-jacent.
Le SDK Rerun 0.32 est une boîte à outils de données unifiée pour l'apprentissage robotique
Rerun 0.32 est la plus grande version depuis son open source initial en février 2023. Elle étend les cas d'utilisation pratiques du SDK, passant de la journalisation, la visualisation et l'interrogation plus simple à l'ensemble du parcours des données, de la collecte à l'entraînement. Ce qui suit est une visite guidée des nouvelles fonctionnalités qui mettent en évidence cette expansion. Consultez les notes de version pour plus de détails.
Un format de fichier stable avec des API Python au niveau des blocs
Dans Rerun 0.23, nous avons annoncé la rétrocompatibilité de version à version pour le format de fichier .rrd de Rerun. En pratique, nous n'avons pas rompu la compatibilité entre les versions depuis lors et nous nous sentons maintenant confiants de promettre une rétrocompatibilité générale sur le format de fichier. Nous continuerons à faire évoluer le format pour pousser les capacités et les performances, mais les anciennes données se chargeront toujours.
Avant la version 0.32, vous ne pouviez écrire des fichiers .rrd qu'en utilisant un importateur depuis un autre format ou les API de plus haut niveau \log\ ou \send_columns\, et la seule façon de lire les données était via des requêtes dataframe ou SQL. Avec cette version, nous introduisons désormais des API de lecture et d'écriture au niveau des blocs, qui vous donnent un contrôle précis sur la forme exacte de vos données.
Prises ensemble, ces deux modifications signifient que .rrd est suffisamment mature pour qu'un large éventail d'équipes puisse construire ses couches de données dessus.
API de traitement de blocs pour le traitement de données robotiques natives
Les données robotiques sont souvent désordonnées. Normaliser les données provenant de multiples sources en quelque chose que les équipes peuvent analyser et sur lequel elles peuvent s'entraîner devient rapidement complexe. Cette partie du pipeline de données consiste souvent en des scripts Python bricolés, lents et pleins de bugs subtils.
Pour résoudre ces problèmes, nous introduisons un nouvel ensemble (expérimental) d'\API de traitement de blocs\. Elles fournissent une interface de chargeur uniforme pour des formats comme .rrd, MCAP, Parquet et URDF qui produisent des flux de blocs Apache Arrow. Vous pouvez ensuite facilement définir des pipelines de traitement au-dessus de ces flux.
Les données robotiques se présentent souvent sous la forme de structures profondément imbriquées, et la normalisation et le traitement des données signifient souvent remodeler, convertir et transformer leur contenu. Pour répondre à ce besoin, nous publions également Lenses, un langage déclaratif pour sélectionner et transformer ce type de données, inspiré de jq.
Ces API ont été explicitement conçues pour et testées avec des agents de codage, et nous constatons qu'ils ont beaucoup plus de facilité à produire un code correct et efficace avec les API de traitement de blocs de Rerun qu'avec du Python générique. À l'avenir, ces transformations de traitement de blocs pourront s'exécuter dans la visionneuse et dans le cloud via Rerun Hub, en plus de l'exécuteur côté SDK actuel.
Prise en charge intégrée étendue pour MCAP, les types ROS 2 et les visualisations robotiques
Nous pensons qu'il est essentiel qu'il soit facile d'ingérer et de rendre toutes les données robotiques utiles dans Rerun. En même temps, il y a beaucoup de données qui peuvent être parfaitement traitées sans personnalisation, et nous continuons à améliorer cette expérience à chaque version. La version 0.32 apporte des performances améliorées et une meilleure prise en charge prête à l'emploi pour MCAP et les types ROS 2 courants, ainsi qu'une expansion des visualisations disponibles. Consultez la liste mise à jour des messages avec prise en charge intégrée ici.
Les grilles d'occupation, ou cartes 2D en 3D, sont importantes pour les robots mobiles et ont été une fonctionnalité très demandée dans Rerun depuis un certain temps. La version 0.32 ajoute donc le nouvel archétype et visualiseur GridMap, associé à une prise en charge intégrée des messages ROS 2 correspondants.
Une autre demande courante a été la capacité de visualiser les changements d'état au fil du temps. La version 0.32 apporte une nouvelle vue expérimentale State Timeline View. Si vous attendiez cette vue dans Rerun, nous aimerions avoir votre avis sur ce que vous aimeriez voir de plus de cette vue.
Serveur de catalogue avec requêtes SQL ou dataframe indexées sur le contenu de nombreux enregistrements sur disque
Les API de catalogue dans le SDK Rerun vous permettent d'écrire des requêtes SQL ou Dataframe entièrement génériques sur des ensembles de données robotiques. Lorsqu'elles sont connectées à Rerun Hub, elles prennent en charge les ensembles de données à grande échelle depuis un certain temps, tandis que le serveur open source ne prenait en charge que les ensembles de données tenant entièrement en mémoire. Avec la version 0.32, nous étendons le serveur de catalogue open source pour indexer les plages d'octets des fichiers sur le disque local, vous permettant ainsi d'analyser facilement n'importe quel répertoire local d'enregistrements robotiques dans des fichiers .rrd avec seulement le SDK open source.
Une nouvelle interface utilisateur pour la révision rapide des ensembles de données pour l'entraînement et l'évaluation
Dans la version 0.32, nous livrons la première version de notre outil de révision d'ensembles de données (expérimental). Il vous permet de jeter un coup d'œil rapide à de nombreux enregistrements à la fois, pour chasser les anomalies et développer une intuition de vos données. Il vous permet également de marquer des enregistrements, ce qui le rend utile comme outil d'annotation simple. La vue est configurée à l'aide d'un blueprint Rerun normal.
De nombreuses équipes d'apprentissage robotique ont demandé cette fonctionnalité et nous aimerions avoir tous vos commentaires sur la façon d'en faire l'outil de révision d'ensembles de données le plus efficace possible.
Un chargeur de données pour l'apprentissage robotique qui prend en charge le mélange simple d'ensembles de données et les recherches aléatoires dans les fichiers .rrd
Nous avons commencé à travailler sur l'une de nos fonctionnalités les plus demandées : un chargeur de données PyTorch pour Rerun ! Le nouveau module rerun.experimental.dataloader expose les enregistrements Rerun sous forme d'ensembles de données PyTorch itérables ou de type carte, diffusant à la volée des images encodées, des scalaires et des vidéos compressées (h264/h265/av1). L'accès aléatoire, la prélecture multi-travailleurs et la prise en charge de DDP fonctionnent immédiatement. Il est compatible à la fois avec le serveur de catalogue OSS et notre produit commercial Rerun Hub pour lorsque vous souhaitez vous entraîner directement sur de grands ensembles de données sauvegardés par le stockage d'objets.
Nous sommes incroyablement enthousiastes à l'idée de publier ce chargeur de données d'entraînement pour que la communauté commence à expérimenter. Nous avons l'intention d'en faire le meilleur chargeur de données en streaming pour l'apprentissage robotique imaginable et nous aimerions recevoir tous vos commentaires et demandes.
Pouvoir s'entraîner directement sur la même couche de données que celle utilisée pour la visualisation, l'analyse et la transformation est crucial pour que les équipes puissent véritablement unifier leurs couches de données, ce qui est la façon dont elles peuvent vraiment simplifier les systèmes et accélérer les cycles d'expérimentation.
Rerun Hub est en aperçu privé et conçu pour l'échelle
Au cours de l'année et demie écoulée, nous avons discrètement construit la couche de données nécessaire pour accélérer l'apport de l'apprentissage robotique à des applications concrètes précieuses, en collaboration avec un premier ensemble de startups et de laboratoires exceptionnels. Nous traitons actuellement des pétaoctets de données d'entraînement robotique et nous sommes à un stade où nous sommes prêts à intégrer davantage d'équipes à notre produit commercial Rerun Hub, qui entre maintenant en aperçu privé.
Rerun Hub est un catalogue et un moteur de stockage qui se connecte au SDK Rerun open source pour faciliter le travail avec les données d'apprentissage robotique, de la collecte à l'entraînement et au déploiement. Il agit comme une couche de gestion et d'accès uniforme qui alimente toutes les capacités de données de base, de l'ingestion, la visualisation, les requêtes analytiques, la transformation et l'entraînement. Les données peuvent être stockées dans n'importe quel stockage d'objets compatible S3, et Rerun Hub orchestre efficacement le streaming sélectif direct du stockage d'objets vers le SDK Rerun dans vos tâches d'entraînement ou de post-traitement massivement parallèles. Le hub centralisé simplifie également la collaboration et la révision automatisée en facilitant la construction de liens de données partageables, soit par code, soit de manière interactive dans la visionneuse.
Si vous construisez des robots intelligents et que vous êtes intéressé par l'amélioration de votre couche de données pour itérer plus rapidement, contactez-nous. Pour les équipes qui ont déjà atteint une certaine échelle avec des systèmes existants complexes, Rerun est facile à adopter progressivement et nous pouvons également proposer des ingénieurs déployés sur le terrain pour vous aider à mettre à niveau sans déplacer les personnes clés d'autres priorités majeures.
