Integration humanoide SONIC de LeRobot : les jetons de mouvement ne sont pas des articulations moteur

Ce que l'integration humanoide de LeRobot ajoute vraiment

L'integration humanoide LeRobot SONIC est interessante parce qu'elle ne demande pas a une politique de tache de piloter directement chaque moteur d'un Unitree G1. C'est le bon reflexe. Une politique humanoide peut predire une representation compacte du mouvement, tandis qu'un controleur local gere le mouvement corps entier et fournit des cibles articulaires pour le suivi bas niveau. Cette separation n'etablit pas un équilibre sûr dans une configuration non testee.

Pour le checkpoint de placement de canette, la politique de tache predit 64 valeurs de jetons de mouvement plus deux champs de pince. Ces 64 valeurs ne sont pas 64 commandes articulaires. Ce sont des coordonnees latentes. Un decodeur embarque combine ce jeton avec l'historique recent de l'etat du robot, puis produit des cibles articulaires pour la boucle de controle proportionnel-derive du robot.

Cette separation est tout l'interet. C'est aussi la que l'integration imprudente peut mal tourner.

Une note d'integration utile, pas un nouveau benchmark

L'article d'integration humanoide LeRobot du 25 septembre explique comment la teleoperation, l'apprentissage de politique et le controle Unitree G1 s'articulent. Le checkpoint et le jeu de donnees de placement de canette etaient deja des artefacts d'aout, donc l'annonce ne doit pas etre lue comme une nouvelle publication de modele avec de nouveaux poids. La partie utile est le schema de cablage, surtout la maniere dont il expose la frontiere entre la sortie de politique et le controle de mouvement embarque.

La premiere question pratique est la compatibilite

La publication decrit un flux de travail. La documentation du controleur decrit le deploiement. Le checkpoint decrit une politique entrainee. Les lire tous les trois ensemble souleve une question simple : le runtime fournit-il les observations que le checkpoint a appris a utiliser ?

Cette question reste non resolue. La politique de canette attend 31 valeurs d'etat. Le controleur SONIC documente expose 64 valeurs d'echo de jeton. Des dimensions d'action communes ne reglent pas la question.

C'est distinct du passage de relais de stockage couvert dans notre analyse de l'integration LeRobot LanceDB. Un jeu de donnees lisible et un checkpoint chargeable sont utiles, mais ils ne prouvent pas qu'un runtime de robot reel alimente la meme representation d'etat que celle apprise par la politique.

Pourquoi la politique de tache n'est pas le controleur d'equilibre

Le jeton n'est pas une liste de moteurs

La publication decrit une representation latente SONIC a 64 dimensions. Le checkpoint de canette ajoute deux champs de pince. Ces coordonnees encodent l'intention de mouvement. Ce ne sont pas des positions articulaires, des cibles de couple ni une liste directe de commandes d'actionneurs.

La documentation G1 decrit SonicWholeBodyController decodant un jeton plus la proprioception recente en une action residuelle. Ce residu est mis a l'echelle et ajoute aux angles debout par defaut, ce qui produit des cibles pour 29 articulations. Le controle PD du robot suit ensuite ces cibles.

Le decodeur charge des poids ONNX et des constantes de deploiement depuis lerobot/sonic_decoder. L'implementation epinglee lit les gains PD, les angles par defaut, l'echelle d'action et un jeton neutre depuis les metadonnees ONNX. Elle separe aussi l'ordre des articulations IsaacLab de l'ordre de deploiement MuJoCo. Ces correspondances ne sont pas de la comptabilite. Elles font partie du contrat de mouvement.

Pour une vue plus large des hypotheses sur le materiel et les controleurs, notre analyse BRIDGE sur la morphologie et le controle est un contexte utile. Elle ne prouve pas que BRIDGE et SONIC partagent une interface.

L'inference distante ne doit pas posseder la boucle locale

Pour le deploiement physique, la documentation decrit un policy_server cote GPU, un robot_client embarque executant le controleur SONIC sur le Jetson du G1, et le pont run_g1_server. Des blocs de jetons circulent sur le reseau. Le controleur embarque est concu pour executer sa boucle documentee a 50 Hz avec la proprioception locale ; le respect reel des echeances doit etre mesure.

Ce schema est une carte conceptuelle de l'interface, pas un deploiement verifie. Le processeur d'observation est laisse non resolu volontairement. Le cycle de retour local ne devrait pas avoir besoin d'un nouveau resultat d'inference GPU a chaque tick du controleur. La mise en tampon peut reduire la dependance a la latence distante, mais elle ne prouve pas un équilibre sûr ni un comportement utile apres une perte reseau.

Le placement asynchrone et le RTC guide sont des reglages differents

Le deploiement asynchrone decide ou l'inference s'execute et comment les blocs d'action atteignent le robot. Le decoupage en temps reel guide, ou RTC, traite la prediction aux frontieres des blocs d'action. La carte du checkpoint de canette recommande le RTC guide, tout en indiquant aussi que ce checkpoint n'a pas ete entraine pour le RTC entraine ni pour piR2.

Ne fusionnez pas ces idees en une seule affirmation. L'echantillonnage du jeu de donnees a 50 fps, un bloc de 50 actions, la cadence de publication et un controleur a 50 Hz sont des quantites separees. Des nombres identiques peuvent etre un indice. Ils ne prouvent pas que les horloges correspondent dans un systeme reel.

La carte d'interface jeton vers mouvement

Commencer par la semantique, puis verifier les formes

La configuration du checkpoint declare observation.state avec la forme [31] et action avec la forme [66]. Le schema du jeu de donnees nomme les champs d'etat : 29 positions articulaires, puis les valeurs de pince gauche et droite. Ses champs d'action sont motion_token_0 a motion_token_63, suivis des pinces.

La partie 5 de la documentation G1 actuelle de la branche main indique plutot que SonicWholeBodyController renvoie un etat d'observation d'echo de jeton a 64 dimensions. La methode observation_state() de l'implementation epinglee confirme qu'elle expose le dernier jeton decode, pas le vecteur mesure d'articulations et de pinces du checkpoint.

C'est le principal ecart d'integration. La compatibilite prete a l'emploi n'est pas etablie. Une equipe doit resoudre le processeur d'observation, la correspondance d'etat physique, la normalisation et la revision du code avant de connecter ces artefacts. Completer un vecteur articulaire ou decouper un vecteur latent permet seulement au tenseur de passer une verification de forme. Cela ne donne pas le meme sens aux valeurs.

Le tableau de la carte du modele decrit aussi l'action comme "64 joints + 2 grippers." Cela contredit les champs nommes de la configuration, le schema du jeu de donnees et l'explication de la publication. Pour cette interface, les artefacts types pesent plus que la formulation du tableau.

Matrice de compatibilite pour tout le chemin de mouvement

La carte d'interface jeton vers mouvement ci-dessous est une synthese editoriale des artefacts inspectes. Ce n'est pas un standard, et ce n'est pas une recette de deploiement testee par Optijara. Son role est de rendre visibles les preuves manquantes avant qu'un runtime soit choisi.

La carte du checkpoint enregistre le code LeRobot 8bf6056d1. Le source du controleur inspecte ici est epingle sur e595b7902714ba51f91e47523f66f89c5181b649. La documentation actuelle de main exige une installation depuis les sources et distingue la version stable v0.6.1. Ses exemples SONIC utilisent nepyope/sonic_walk, pas le checkpoint de canette. Traitez-les comme des references liees, pas comme des instructions interchangeables.

{
  "contract": {
    "checkpoint_state": "29 positions articulaires plus 2 pinces",
    "checkpoint_action": "64 coordonnees SONIC plus 2 pinces",
    "documented_controller_state": "echo de jeton a 64 valeurs"
  },
  "proposedchecks": ["Resoudre le processeur d'observation", "Verifier les noms et la normalisation", "Epingler des revisions runtime compatibles"],
  "limitations": ["Compatibilite prete a l'emploi non resolue", "Aucun test d'inference, de simulation ou de materiel effectue pour cet article"]
}

Ce que montre le checkpoint de canette, et ce qu'il ne montre pas

Lire la tache, les cameras et le timing comme un contrat

La carte du jeu de donnees can_clean_final decrit 105 episodes et 212 290 images a 50 fps. Les trois flux camera 480 par 640 sont ego_view, left_wrist et right_wrist. La tache unique est Bring the can to the white table. Ces details definissent le contrat d'entree du checkpoint. Ils n'etablissent pas les performances dans une autre piece, avec un autre montage de camera ou sous une instruction de tache differente.

Le jeu de donnees documente action[t] comme la commande qui produit observation.state[t+1]. Preservez cette relation lors de la construction d'exemples de relecture. L'etat au meme indice ne doit pas devenir en silence le resultat attribue a l'action.

La carte indique aussi que observation.state[29] et action[64], les champs de pince gauche, sont toujours a zero. En pratique, les enregistrements etaient faits d'une seule main. Deux champs de sortie de pince ne fournissent pas de preuve d'une competence bimanuelle.

La normalisation demande le meme soin. La configuration specifie une normalisation par quantiles pour l'etat et l'action. La carte du jeu de donnees indique que les bornes de quantile de la pince gauche ont ete fixees manuellement pour eviter une division par zero. Une migration de processeur doit preserver ce traitement au lieu de lire un comportement utile de la main gauche dans une plage numerique valide.

La perte n'est pas une affirmation de succes de tache

Le jeu de donnees a ete examine et les echecs ont ete retires. La carte du checkpoint indique une perte d'entrainement finale de 0,025, explicitement sans separation de validation. C'est une metadata d'entrainement utile. Ce n'est pas un succes de tache autonome, et ce n'est pas une preuve de generalisation.

La lecture equitable est plus etroite : ces artefacts documentent une configuration d'entrainement et exposent des contraintes qu'une evaluation compatible doit respecter. Les affirmations de capacite ont besoin de preuves separees en boucle fermee. Budgetisez explicitement la verification des hypotheses d'interface et l'evaluation du comportement, au lieu de traiter la disponibilite des artefacts comme une preuve de compatibilite.

Un guide d'adoption avec simulation d'abord pour la pile de mouvement G1

Etape 1 : reconcilier le contrat hors ligne

Toutes les verifications ci-dessous sont proposees. Optijara n'a execute aucun test d'inference, de simulation, d'entrainement ou de robot physique pour cet article.

Commencez par l'inspection des artefacts. Epinglez les revisions. Comparez les noms et les unites d'etat. Confirmez l'ordre des articulations. Tracez les deux pinces separement. Comparez les identites des cameras et le pretraitement avec le checkpoint, pas seulement les dimensions d'image. Inspectez la normalisation de l'etat et de l'action ainsi que les constantes du decodeur. Traitez la correspondance non resolue entre observations 31 et 64 comme une condition d'arret.

C'est aussi le moment de verifier l'alignement temporel. Un pipeline de relecture qui fournit les bons champs au mauvais pas de temps n'a pas reproduit l'interface d'entrainement. Consignez les decisions du processeur afin qu'un autre ingenieur puisse distinguer les transformations deliberees des coercitions accidentelles.

Etape 2 : separer le timing de politique du timing de controleur

Une fois les outils et les correspondances compatibles resolus, executez une relecture hors ligne ou une simulation de l'interpretation jeton vers cible avant de juger le comportement appris de la tache. La documentation fournit des exemples de simulation, mais cela ne montre pas qu'un simulateur inchange reproduit exactement cette pile de politique de canette.

Definissez des seuils d'acceptation pour la configuration visee avant les tests. Cet article ne fournit pas de valeurs de securite universelles par defaut. Consignez la cadence de publication et la consommation de file avec la latence d'inference ; une moyenne correcte peut masquer des interruptions. Pour une discussion complementaire de la preuve comportementale, consultez notre carte d'evaluation robotique video vers tache.

Etape 3 : decider si la preparation materielle est justifiee

Adoptez maintenant l'inspection de l'interface. Ne migrez les processeurs qu'apres en avoir stabilise le sens. Ne transplantez pas une commande de carte de checkpoint dans du code materiel actuel de main simplement parce que les deux mentionnent Unitree G1.

Avant tout essai physique, exigez les procedures de securite du fabricant, une zone de test controlee et un arret d'urgence fonctionnel. Examinez explicitement le comportement en cas de file perimee et de perte reseau. Cet article n'etablit pas de watchdog par defaut et ne recommande pas de test materiel synchrone rapide.

Erreurs courantes et limites a garder visibles

Erreurs qui rendent l'interface plus sure qu'elle ne l'est

• Traiter les coordonnees latentes comme des articulations moteur ignore le role du decodeur. Tracez le decodage des jetons et la conversion de l'ordre articulaire.
• Faire correspondre les dimensions d'action tout en ignorant le sens des observations laisse l'entree de politique non resolue. Verifiez les deux cotes du contrat.
• Appeler 50 Hz la vitesse de la politique confond le controle local avec le debit d'inference. Mesurez-les separement.
• Inferer une competence bimanuelle a partir de deux champs de sortie ignore la pince gauche inactive dans les enregistrements.
• Traiter le RTC guide comme un déploiement asynchrone sûr confond la prediction de blocs avec le placement runtime et la gestion des defaillances.

Licences, securite et compromis operationnels

La liste de fichiers du decodeur SONIC inspectee expose des artefacts de decodeur mais pas de carte de modele ni de fichier de licence visible. Cette absence n'est pas une conclusion juridique. Examinez separement les termes du modele de base, du decodeur, du logiciel de controle, du jeu de donnees et du materiel ; une licence de bibliotheque ou de jeu de donnees n'accorde pas d'autorisation pour chaque composant.

La derive de la branche main et les processeurs de l'epoque du checkpoint compliquent la reproductibilite. Le placement des cameras, les conventions de proprioception et les differences d'execution GPU doivent aussi etre examines. Si les observations camera quittent le robot pour une inference distante, evaluez les controles d'acces et la confidentialite pour l'environnement operationnel.

Budgetisez le travail d'integration et d'evaluation sans supposer une preparation pour la production. La decision immediate est de savoir si une equipe peut etablir un contrat coherent observation vers jeton vers mouvement, avec les hypotheses non resolues visibles avant la preparation materielle.