Qu’est-ce qu’une politique de robot ? De l’observation à l’action
Une politique de robot associe l’observation à l’action. Découvrez comment la fréquence de sortie, le format d’action, la mémoire et le déterminisme décident exactement des données que vous devez capturer.
Retirez le vernis marketing d’un robot humanoïde et un seul objet trône en plein centre : une fonction. Elle prend ce que le robot perçoit à l’instant présent et renvoie ce que les moteurs doivent faire ensuite. Les roboticiens appellent cette fonction la politique (policy), et presque chaque décision conséquente dans un stack d’apprentissage robotique est en secret une décision sur la forme de la politique.
Vous pouvez ignorer la politique et livrer quand même une démo. Vous ne pouvez pas l’ignorer et comprendre pour autant pourquoi un jeu de données entraîne une compétence robuste tandis qu’un autre, plus grand et plus coûteux, en entraîne une fragile. La politique est le point de rencontre entre les données et le comportement : c’est donc le bon endroit où commencer.
Cet article définit la politique aussi simplement que possible, puis montre comment sa forme remonte la chaîne de traitement et détermine ce que vous devez capturer.
Observation en entrée, action en sortie
Au fond, une politique est une application. Donnez-lui une observation, c’est-à-dire la vue qu’a le robot du monde à l’instant présent, et elle renvoie une action, la commande qui met le corps en mouvement. Faites tourner cette boucle des dizaines ou des centaines de fois par seconde et vous obtenez un comportement. Tout le reste, le réseau de neurones, l’objectif d’entraînement, le jeu de données, n’existe que pour produire une bonne version de cette unique application.
Deux détails rendent cette définition utile plutôt que triviale. Premièrement, ce qui compte comme observation relève d’un choix : les pixels d’une caméra, ou les pixels plus les angles articulaires plus les forces de contact. Deuxièmement, ce qui compte comme action relève aussi d’un choix : une position articulaire cible, une variation de pose de l’effecteur terminal, ou un token discret issu d’un vocabulaire appris. Des boîtes à outils comme LeRobot rendent ces choix explicites dans leur schéma de données, signe que le domaine les prend désormais au sérieux.
Il est utile de dire ce qu’une politique n’est pas. Ce n’est pas un plan établi à l’avance, et ce n’est pas un script figé. Une bonne politique est en boucle fermée : elle relit le monde à chaque top d’horloge et peut réagir à une tasse qui a glissé ou à une cheville qui s’est coincée. C’est toute cette réactivité qui rend l’imitation à partir d’une vidéo statique difficile, et qui explique pourquoi l’observation que vous fournissez à la politique doit arriver assez vite pour compter.
Une politique a une forme, et cette forme a des conséquences
Toutes les politiques ne sont pas construites de la même façon, et les différences ne sont pas cosmétiques. Quatre axes comptent avant tout.
Fréquence de sortie
Une politique qui produit sa sortie à 10 Hz et une autre qui la produit à 200 Hz sont deux bêtes différentes. La lente peut s’appuyer sur un lourd backbone visuel et planifier posément. La rapide doit être assez légère pour fermer une boucle de commande en quelques millisecondes à un chiffre. Les compétences riches en contacts ont généralement besoin de la boucle rapide, et cette exigence remonte jusqu’à la vitesse à laquelle vous devez capturer.
Représentation de l’action
Les positions articulaires absolues, les deltas d’effecteur terminal et les actions tokenisées impliquent chacun un jeu de données différent et une histoire de généralisation différente. Un delta d’effecteur terminal se transfère d’un corps de robot à l’autre plus gracieusement qu’une commande articulaire brute, ce qui compte dès l’instant où vous tentez de mutualiser des données entre incarnations, comme l’a constaté Open X-Embodiment.
Mémoire
Une politique markovienne ne voit que l’image courante. Une politique dotée d’un historique peut se souvenir qu’elle a déjà saisi la vis et qu’elle la transporte à présent. La mémoire vous achète un comportement à long horizon et vous coûte des séquences propres et temporellement cohérentes dans les données, au lieu d’images isolées mélangées.
Déterminisme
Une politique qui régresse vers une action unique moyennera deux options aussi bonnes l’une que l’autre en une mauvaise. Une politique générative, un modèle de diffusion ou un échantillonneur de tokens, garde les options séparées. Ce choix détermine si vos données peuvent contenir plusieurs façons valides d’accomplir la même tâche, ou doivent être filtrées jusqu’à n’en garder qu’une. En manipulation, cela apparaît sans cesse : il existe de nombreuses bonnes façons de saisir une tasse, et une politique forcée de choisir une seule prise moyenne ira souvent chercher l’espace vide entre deux d’entre elles.
| Choix de conception | Options typiques | Ce qu’il exige des données |
|---|---|---|
| Fréquence de sortie | 10 Hz en planification, 200 Hz en commande | Capturer à la fréquence de commande ou au-dessus, avec un horodatage précis |
| Représentation de l’action | Position articulaire, delta d’effecteur terminal, tokens | Des repères et un étalonnage cohérents sur chaque démonstration |
| Modalités d’observation | RGB, plus profondeur, plus proprioception et force | Chaque modalité synchronisée sur une même horloge |
| Mémoire | Markov, ou historique et récurrence | Des séquences ininterrompues, pas des images mélangées |
| Déterminisme | Régression, ou génératif | L’autorisation de conserver plusieurs solutions valides par tâche |
Lire un stack réel à travers le prisme de la politique
Regardez les systèmes actuels sous cet angle et ils deviennent plus faciles à comparer. GR00T de NVIDIA est une politique de fondation destinée à être adaptée à de nombreux humanoïdes ; elle s’appuie donc sur des actions centrées sur l’effecteur terminal et un pré-entraînement large. pi0 de Physical Intelligence et les grands modèles de comportement de Toyota Research Institute misent tous deux sur le clonage à partir de vastes ensembles de démonstrations variés. Le fil conducteur, c’est que la décision de conception phare de chaque projet, la forme de sa politique, a dicté la forme des données qu’il devait rassembler. Une grande partie des travaux récents d’apprentissage robotique sur arXiv se lit comme un débat sur la forme de politique qui rentabilise le mieux le coût des données qu’elle exige.
Comparer ces systèmes par leurs scores de benchmark ne vous apprend pas grand-chose, car ils exécutent rarement le même benchmark sur le même matériel. Les comparer par la forme de leur politique vous en apprend beaucoup : cela prédit de quelles données chacun est avide, et donc où chacun peinera à passer à l’échelle.
Une politique est un pari sur la quantité d’information suffisante pour choisir l’action suivante. Le jeu de données est la preuve de ce pari, et aucun entraînement, si intense soit-il, ne peut ajouter une preuve que la capture n’a jamais enregistrée.
Petite définition, grandes conséquences
Demandez ce qu’est une politique de robot et la réponse honnête est modeste : une fonction de l’observation vers l’action. Demandez ce qui découle de sa forme et la réponse, c’est presque tout le domaine. La fréquence de sortie, la représentation de l’action, la mémoire et le déterminisme ne sont pas des broutilles d’implémentation. Ce sont les questions qui décident, avant le moindre pas de gradient, de ce que vos données doivent contenir. Clarifiez d’abord la forme de la politique dans votre tête, et les exigences en matière de données cessent d’être un mystère pour devenir une spécification. C’est le bénéfice discret de l’abstraction : nommez l’application, fixez sa forme, et le débat sur les données cesse de tourner en rond.