Robo-DM: Data Management For Large Robot Datasets

Auteurs: Kaiyuan Chen, Letian Fu, David Huang, Yanxiang Zhang, Lawrence Yunliang Chen, Huang Huang, Kush Hari, Ashwin Balakrishna, Ted Xiao, Pannag R Sanketi, John Kubiatowicz, Ken Goldberg · ICRA 2025

Licences

• Accès libre
• Article: CC BY 4.0

Tout ce qui suit s'appuie sur l'article complet sous sa licence CC BY 4.0 ; sa figure est montrée en citant les auteurs.

En bref

Robo-DM stocke les flux vidéo, langage et action de chaque épisode robotique dans un seul fichier EBML horodaté, ce qui réduit la taille jusqu'à 70x par rapport à RLDS et charge plus vite que LeRobot.

Pourquoi c'est important

La taille d'un jeu de données détermine à la fois la facture de téléchargement de l'hébergeur et le temps qu'une tâche d'entraînement attend les données, de sorte que des fichiers plus petits et rapides à charger réduisent le coût du partage et de l'utilisation de grands jeux de données robotiques. Dans les expériences Octo et ICRT, la compression vidéo avec perte à ces taux a modifié la perte de validation de 2,6 % et n'a pas empêché une politique de réussir les 15 essais physiques de saisie-dépose.

Problème

Les grands jeux de données robotiques téléopérées comme Open X-Embodiment sont coûteux à partager et lents à charger : stocker 8,9 TB sur Google Cloud coûte 172 USD par mois, mais chaque téléchargement complet coûte à l'hébergeur entre 172 et 1 540 USD. Les formats existants soit stockent les images sous forme de matrices (RLDS, HDF5), ce qui est sans perte mais peu économe en espace, soit dispersent les flux dans plusieurs fichiers avec des hypothèses d'alignement propres à un cadre (LeRobot), ce qui complique le chargement et ralentit le décodage.

Solution proposée

Robo-DM étend Extensible Binary Meta Language (EBML), le conteneur à la base de la vidéo MKV, pour stocker tous les flux de vision, de langage et d'action d'un épisode dans un seul fichier autonome, chaque paquet étant marqué d'un horodatage relatif au début de l'épisode. Les données sont enregistrées brutes et transcodées après la collecte avec des codecs avec perte (par exemple AV1) ou sans perte (FFV1) ; au moment de l'entraînement, un répartiteur de charge choisit entre décoder la vidéo et lire des caches mappés en mémoire d'images décodées. Il fonctionne avec ROS 2 (rosbag, rviz, Foxglove), TensorFlow et PyTorch, et exporte vers HDF5 et RLDS.

Idées clés

• La majeure partie de la réduction de taille provient de la compression vidéo des flux des caméras, comme l'indiquent les auteurs.
• Conserver tous les flux dans un seul conteneur horodaté supprime le besoin d'heuristiques pour aligner des flux enregistrés à des fréquences différentes.
• Reporter la compression après la collecte évite que le transcodage n'interfère avec la collecte des données.
• Les petits épisodes gagnent moins : RT-1 compte en moyenne 1,51 MB par trajectoire en RLDS, et les métadonnées de recherche et de décodage de Robo-DM limitent la réduction à 4,39x.

Principaux résultats

• Robo-DM avec perte par rapport aux fichiers RLDS d'origine (Table I) : Bridge de 387,49 GB à 5,31 GB (73x), Cable Routing de 4,67 GB à 0,26 GB (18x), Door Opening de 7,12 GB à 0,10 GB (71x), AutoLab UR5 de 76,39 GB à 3,26 GB (23x). Le texte donne ces valeurs comme 18x, 73x, 23x et 73x ; le résumé annonce jusqu'à 70x avec perte et 3,5x sans perte.
• Débit de chargement sur trois jeux de données OXE (Fig. 4) : plus rapide que LeRobot de 33x, 20x et 5x, la version sans perte étant proche de la version avec perte ; le résumé annonce jusqu'à 50x plus rapide que LeRobot en décodage séquentiel. HDF5 était plus rapide que Robo-DM parce que ses données ne sont pas compressées.
• Ajustement fin d'Octo-small sur RT-1 (de 111,06 GB à 36,50 GB, 4,39x) : 0,02 s de chargement des données et 0,10 s d'entraînement par itération avec une taille de lot de 64, comme le chargeur TensorFlow ; MSE de validation de 1,86 avec les données sans perte et de 1,91 avec les données avec perte, soit une hausse de 2,6 %.
• L'introduction indique que, pour l'ajustement fin d'Octo, Robo-DM charge 3,0x plus vite avec une petite taille de lot et n'ajoute aucun ralentissement avec une grande taille de lot.
• ICRT sur un bras Franka, entraîné sur 335 démonstrations stockées en 77 MB avec perte (75,3x à partir de 5,8 GB de HDF5 gzip) ou 1,7 GB sans perte (3,41x) : 15 essais de saisie-dépose sur 15 ont réussi avec le modèle entraîné sur les données avec perte.

Limites

• Utiliser la RAM comme cache de décodage augmente l'usage mémoire et peut réduire le débit lorsque les données par épisode sont volumineuses ; sur Bridge, le débit a baissé quand la taille de lot augmentait, et échantillonner une seule image par épisode peut être plus lent (indiqué par les auteurs).
• Le décodage utilisait PyAV sur le CPU sans accélération GPU ; les auteurs citent Decord et NVIDIA NVDEC comme options plus rapides pour des travaux futurs.
• Les petits épisodes se compressent moins en raison des métadonnées de recherche et de décodage propres à chaque fichier (4,39x sur RT-1).
• La vérification physique consiste en une seule tâche de saisie-dépose avec 15 essais d'un modèle entraîné sur des données avec perte, sans modèle équivalent entraîné sur des données non compressées.
• La conversion de LeRobot supprime le flux de profondeur et certains flux d'action, de sorte qu'il n'y a pas de chiffre de taille LeRobot pour AutoLab UR5.

Impact sur le domaine

A remporté le prix IEEE ICRA 2025 Best Paper Award on Robot Learning ; 5 citations. Les auteurs publient Robo-DM en open source, avec le code et les scripts d'évaluation sur github.com/BerkeleyAutomation/fog_x.

Résumé

Des résultats récents suggèrent que de très grands jeux de données de démonstrations robotiques téléopérées peuvent servir à entraîner des modèles fondés sur des Transformer, susceptibles de généraliser à de nouvelles scènes, de nouveaux robots et de nouvelles tâches. Cependant, la curation, la distribution et le chargement de grands jeux de données de trajectoires robotiques, qui se composent généralement de modalités vidéo, textuelles et numériques, y compris des flux provenant de plusieurs caméras, restent difficiles. Nous proposons Robo-DM, une boîte à outils de gestion de données efficace, open source et fondée sur le cloud, pour collecter et partager des données robotiques et apprendre à partir de celles-ci. Avec Robo-DM, les jeux de données robotiques sont stockés dans un format autonome avec Extensible Binary Meta Language (EBML). Robo-DM peut réduire considérablement la taille des données de trajectoires robotiques, les coûts de transfert et le temps de chargement des données pendant l'entraînement. Par rapport au format RLDS utilisé dans les jeux de données OXE, la compression de Robo-DM économise jusqu'à 70x d'espace (avec perte) et 3,5x (sans perte). Robo-DM accélère aussi la récupération des données en répartissant la charge du décodage vidéo avec des caches de décodage mappés en mémoire. Par rapport à LeRobot, un cadre qui utilise lui aussi une compression vidéo avec perte, Robo-DM est jusqu'à 50x plus rapide en décodage séquentiel. Nous évaluons physiquement un modèle entraîné par Robo-DM avec compression avec perte, une tâche de saisie-dépose et In-Context Robot Transformer. Robo-DM utilise une compression 75x du jeu de données d'origine et ne subit aucune baisse de précision sur la tâche en aval. Le code et les scripts d'évaluation se trouvent sur le site https://github.com/BerkeleyAutomation/fog_x.

Liens

• arXiv 2505.15558: https://arxiv.org/abs/2505.15558
• DOI 10.1109/ICRA55743.2025.11128693: https://doi.org/10.1109/ICRA55743.2025.11128693
• PDF: https://arxiv.org/pdf/2505.15558v1
• Code: https://github.com/BerkeleyAutomation/fog_x