Hz et fps : cadence de capture et fréquence de contrôle d’un robot
Pourquoi un rig robotique échantillonne à 240 Hz alors qu’une policy agit à 30 Hz, en quoi cadence de capture et fréquence de contrôle diffèrent, et ce que coûte la détection multi-cadence.
Une caméra fixée sur un rig de pliage de linge capture 240 images par seconde. La policy qui pilote le préhenseur se réveille 30 fois par seconde. Même robot, même serviette, et un écart d’un facteur huit entre la vitesse à laquelle les deux moitiés du système perçoivent le monde et celle à laquelle elles agissent dessus.
Cet écart n’est pas de l’ingénierie bâclée. C’est un choix de conception que l’on retrouve dans presque toutes les piles de manipulation sérieuses commercialisées aujourd’hui, et les chiffres qui le sous-tendent, 240 Hz ici, 30 Hz là, 50 Hz quelque part entre les deux, sont d’ordinaire rapportés avec assez d’imprécision pour que les néophytes les croient interchangeables. Ils ne le sont pas. Hz et fps mesurent des grandeurs liées mais distinctes, et les confondre, c’est ainsi qu’un jeu de données finit avec une vidéo magnifiquement nette dont une policy est en réalité incapable d’apprendre.
Cet article dissocie les deux cadences : ce qu’une cadence de capture élevée vous apporte, pourquoi la fréquence de contrôle reste obstinément basse, et ce qui doit se produire entre les deux pour qu’un modèle entraîné sur des données de démonstration humaine ne s’étrangle pas avec ses propres horodatages.
Deux horloges qui s’accordent rarement
Commençons par le vocabulaire, car c’est là que naît l’imprécision. Les fps, images par seconde, sont une cadence d’échantillonnage : la fréquence à laquelle un capteur écrit un échantillon. Les Hz ne sont que des cycles par seconde, et cette unité s’attache à chaque horloge du système : l’exposition de la caméra, l’échantillonnage de l’IMU, la lecture du force-couple, la boucle de contrôle, l’étape d’inférence de la policy. Dire qu’un robot tourne à « 240 » n’a aucun sens tant que vous n’avez pas précisé 240 de quoi.
Un rig de manipulation typique fait tourner au moins quatre horloges à la fois. Des caméras RGB à 30 à 60 fps, la profondeur parfois plus bas. Une centrale inertielle à 100 à 1000 Hz. Un capteur de force-couple à 500 Hz jusqu’à quelques kHz. Et la boucle de contrôle, ce qui commande réellement les consignes articulaires, souvent à seulement 15 à 50 Hz pour une policy apprise, alors même que le contrôleur moteur sous-jacent ferme sa boucle de courant à 1 kHz ou plus. Cinq horloges, séparées de trois ordres de grandeur, et chacune d’elles doit être réconciliée avant qu’un modèle ne voie le moindre échantillon.
Pourquoi la capture veut être rapide
L’argument en faveur d’une cadence de capture élevée est physique, pas esthétique. Trois raisons dominent.
Le contact est rapide. À l’instant où le bout d’un doigt touche un objet rigide, la force bondit en une milliseconde ou deux. Échantillonnez ce canal à 30 Hz et vous manquez complètement le transitoire : vous voyez « pas de contact », puis « déjà en appui », sans rien entre les deux. La qualité de préhension, le glissement et l’impact vivent tous dans cet interstice, et c’est pourquoi les canaux de force-couple sont lus à des centaines de hertz, voire davantage.
Nyquist est impitoyable. Pour reconstruire un signal, il faut l’échantillonner à plus du double de sa fréquence la plus élevée. Une vibration de tendon ou un broutage d’outil à 80 Hz exige plus de 160 Hz rien que pour éviter un repliement de spectre qui le transforme en bruit. Le sous-échantillonnage ne rend pas le signal flou : il fabrique un faux signal, de fréquence plus basse, qui semble parfaitement réel.
Le flou, c’est de l’information perdue. Une caméra à 30 fps avec une longue exposition étale un préhenseur rapide sur toute l’image. Des cadences d’images plus élevées, avec des expositions plus courtes, gardent des contours nets, ce qui compte davantage pour un modèle qui lit un mouvement fin que pour un humain qui regarde la lecture.
Capturez le monde à la vitesse de l’événement le plus rapide qui vous importe, puis confiez à la policy la cadence la plus lente sur laquelle elle peut encore agir correctement. Ce sont deux nombres différents, et faire comme s’ils n’en étaient qu’un, c’est l’erreur classique du débutant.
Pourquoi le contrôle reste lent
Si la vitesse est si bénéfique, pourquoi ne pas faire tourner la policy à 240 Hz elle aussi ? Parce que la policy coûte cher et que le monde est indulgent.
Un modèle vision-langage-action (VLA) moderne est un grand réseau de neurones. Une passe avant peut prendre des dizaines de millisecondes sur un GPU de datacenter, et davantage sur tout ce que l’on peut fixer à un robot. Exécutez l’inférence à chaque tick de contrôle et il vous faudrait une passe avant de moins de 5 ms, qu’aucun modèle de taille intéressante ne fournit. Le domaine découple donc les deux cadences par le découpage en actions (action chunking) : la policy observe la scène une fois, prédit une courte séquence d’actions futures, et un contrôleur moins coûteux les diffuse pendant que l’inférence suivante s’exécute. Le π0 de Physical Intelligence utilise le flow matching pour émettre des blocs d’actions à environ 50 Hz au maximum, tandis que le lourd transformer bat bien moins souvent, et le GR00T de NVIDIA suit le même schéma de prédiction par blocs.
La deuxième raison, c’est que la manipulation le tolère. Plier une serviette ou emboîter un connecteur est quasi statique : le bras se déplace lentement par rapport à la perception, et un flux de commandes à 30 Hz est assez fluide. Les tâches dynamiques, une allure de course, une réception au vol, un coup de fouet, exigent des cadences de contrôle plus élevées et, en général, un contrôleur différent, non appris, en dessous.
| Signal ou boucle | Cadence typique | Pourquoi cette cadence |
|---|---|---|
| Caméra RGB | 30-60 fps | Suffisant pour la manipulation lente, limité par la bande passante et le stockage |
| Force-couple | 500 Hz à quelques kHz | Les transitoires de contact sont à l’échelle de la milliseconde |
| IMU | 100-1000 Hz | Vibration et rotation rapide se replient en deçà |
| Policy apprise (contrôle) | 15-50 Hz | Limité par la latence d’inférence du modèle |
| Boucle de courant moteur | 1 kHz et plus | Stabilité de l’asservissement bas niveau |
La taxe d’alignement
Plusieurs horloges créent un problème de comptabilité facile à sous-estimer. Si votre caméra horodate une image à t et que votre capteur de force horodate une lecture à t plus 3 ms, quelle action le modèle associe-t-il à quelle observation ? Trompez-vous et vous enseignez à la policy un mensonge causal : appuyer, puis voir, au lieu de voir, puis appuyer.
Aussi, tout jeu de données sérieux ré-échantillonne. Les flux bruts arrivent à leurs cadences natives et sont alignés sur une chronologie commune, généralement la cadence de contrôle, par interpolation ou appariement au plus proche voisin, canal par canal. C’est là que la formule « capture à 240 Hz, sortie à 30 Hz » prend tout son sens : vous enregistrez vite pour attraper les événements rapides, puis vous sous-échantillonnez délibérément à la cadence que consomme la policy, tout en gardant les canaux à haute cadence disponibles pour quiconque en aura besoin plus tard. Le format de jeu de données LeRobot de Hugging Face inscrit des horodatages par caractéristique précisément pour que cet alignement soit reproductible et non affaire de tradition orale.
Jetez les horodatages et vous ne pourrez plus jamais refaire l’alignement. C’est la raison discrète pour laquelle une capture brute, à haute cadence et bien horodatée vaut davantage que des clips préconfectionnés à 30 Hz : les clips ont déjà fait des choix que vous ne pourrez jamais revoir.
Les cadences réelles des jeux de données publics
Les chiffres des corpus ouverts rendent l’écart concret.
- DROID associe un bras Franka à trois vues de caméra et publie des trajectoires à une cadence de contrôle de l’ordre de 15 Hz, un chiffre délibérément modeste, choisi pour qu’une policy apprise puisse suivre. Voir le jeu de données DROID.
- Ego4D, des milliers d’heures de vidéo humaine à la première personne, est distribué à 30 fps : correct pour lire l’intention humaine et le mouvement de la main, grossier pour le contact rapide, ce qui est exactement le compromis que ses concepteurs ont accepté pour gagner en échelle. Voir Ego4D.
- Open X-Embodiment assemble plus de soixante jeux de données couvrant 22 morphologies de robots dont les fréquences de contrôle s’étalent d’environ 3 à 30 Hz, et c’est pourquoi quiconque s’entraîne sur l’ensemble doit d’abord ré-échantillonner. Un modèle qui ignore ce décalage apprend à travers des horloges incohérentes. Voir Open X-Embodiment.
Alors, la prochaine fois qu’une fiche technique se vante d’un seul grand chiffre, demandez 240 de quoi, et par rapport à quelle horloge. L’ingénierie intéressante n’est jamais dans la cadence de pointe. Elle est dans l’écart honnête entre la vitesse à laquelle un robot perçoit le monde et celle à laquelle il ose agir, et dans le fait de garder assez du signal rapide sous la main pour que le choix vous reste à refaire.