Unitree G1 : l’inférence sur le robot ou dans le cloud ?

Votre modèle de vision répond trop tard dès que le réseau ralentit, ou vous hésitez à envoyer les images du robot hors du laboratoire ?

Cette semaine, séparez d’abord le contrôle du mouvement et les fonctions de sécurité des tâches de perception ou d’analyse. Gardez sur le robot toute boucle qui doit continuer à fonctionner sans réseau ; évaluez le cloud pour les calculs tolérant une attente et pour les traitements centralisés. Le choix ne dépend pas seulement du Unitree G1 : il doit être validé pour votre tâche, vos interfaces et votre matériel.

Cet article s’adresse aux ingénieurs en algorithmes qui répartissent vision, planification et modèles d’action ; aux responsables de laboratoire qui arbitrent entre calcul local et ressources partagées ; et aux équipes d’intégration qui doivent prévoir un comportement sûr en cas de coupure réseau.

La criticité de la tâche détermine le lieu d’exécution

Il est tentant de choisir un seul emplacement pour « l’IA du robot ». En pratique, cette formule regroupe des fonctions qui n’ont ni les mêmes contraintes ni les mêmes conséquences en cas de retard. Une perception destinée à produire un compte rendu après l’essai peut attendre. Une commande qui participe au maintien de l’équilibre ne peut pas être traitée comme une requête distante ordinaire.

Commencez par distinguer les fonctions selon ce qui arrive si le résultat tarde, est incorrect ou ne revient pas :

Famille de tâche	Conséquence d’un retard ou d’une coupure	Orientation à tester
Mouvement, stabilisation et fonctions de sécurité	Le robot peut ne plus recevoir à temps les données ou commandes nécessaires à son comportement sûr.	Garder la boucle critique sur le robot ou dans une architecture locale validée.
Perception utilisée pour une réaction immédiate	Une image ancienne peut conduire à une décision qui ne correspond plus à la scène.	Privilégier l’exécution locale si la réponse conditionne une action rapide ; tester le cloud seulement si un résultat tardif est acceptable.
Planification de haut niveau	Une attente peut parfois être tolérée si le robot conserve un état sûr et sait patienter.	Évaluer une architecture distante avec repli local explicite.
Analyse après essai, annotation ou comparaison de modèles	Le traitement n’intervient pas nécessairement dans la commande en cours.	Le cloud ou un poste de calcul centralisé peut être étudié, sous réserve des règles de données et d’accès.

Le Unitree G1 peut-il utiliser une inférence IA dans le cloud ? Oui, une équipe peut étudier une architecture où une partie des calculs est distante, mais cela ne prouve pas qu’une fonction précise soit compatible avec le robot. La page officielle du Unitree G1 présente le produit ; elle ne constitue pas, à elle seule, une validation de votre architecture d’inférence distante. Pour les interfaces, le matériel et les logiciels, vérifiez les ressources officielles de développement Unitree, puis validez le chemin réel avec votre équipe.

Pour chaque fonction, notez son entrée, son résultat, son rythme de mise à jour attendu et ce que le système doit faire si le résultat manque. Vous obtenez ainsi une frontière d’architecture plus utile qu’une règle générale du type « tout sur le robot » ou « tout dans le cloud ».

La latence de bout en bout compte davantage que celle du modèle

Une inférence rapide ne garantit pas une réaction rapide. Le temps utile au système comprend l’acquisition du capteur, le transfert des données, le prétraitement, l’inférence, le retour du résultat et son application par la commande. Si le modèle s’exécute à distance, la communication et ses variations s’ajoutent à la chaîne. Mesurer uniquement le temps d’exécution du modèle masque donc une partie du risque.

Dans votre essai, horodatez les étapes avec une référence cohérente et conservez les mesures par séquence. Examinez la latence médiane et les valeurs élevées, plutôt que de ne retenir qu’une moyenne. Relevez également la perte de paquets, les délais de retour et les erreurs de synchronisation. Ces paramètres sont des mesures à produire sur votre installation, pas des performances garanties du robot ou du cloud.

Mesure à relever	Pourquoi elle aide à décider	Ce qu’il faut regarder
Temps capteur-résultat-action	Il reflète le chemin complet, pas seulement le calcul.	Les cas habituels et les retards extrêmes pendant l’essai.
Perte de paquets et variation du délai	Une connexion fluctuante peut être plus problématique qu’un délai moyen stable.	La fréquence des pertes et la capacité du système à les tolérer.
Délai avant repli	Il indique combien de temps le robot attend avant de changer de stratégie.	Le comportement réel lorsque le service distant ne répond plus.
Coût de calcul et de transfert	Il rend visibles les dépenses qui ne figurent pas dans le temps d’inférence.	Calcul, stockage, transfert, exploitation et temps consacré au dépannage.

Quel délai supplémentaire entraîne une vision dans le cloud ? Il n’existe pas de valeur fixe à déduire du seul modèle ou du nom du robot. Le résultat dépend notamment de la taille des données, du réseau entre le robot et le calcul distant, de la charge du service, du prétraitement et de la façon dont le résultat est réinjecté dans le système. Mesurez la chaîne complète dans votre environnement, puis comparez-la à une exécution locale sur la même tâche et avec les mêmes entrées.

La qualité de service du middleware peut aussi influer sur ce qui est transmis et sur la manière dont les pertes sont gérées. La documentation de conception de ROS 2 sur les profils de qualité de service décrit notamment des politiques de fiabilité, de durée de conservation et de détection d’activité. Utilisez ces réglages comme des paramètres à vérifier dans votre propre architecture ; ils ne remplacent pas un essai de bout en bout et ne garantissent pas une compatibilité particulière avec le G1.

Le réseau et les données imposent des contraintes d’exploitation

Une solution cloud dépend d’un chemin réseau disponible au moment voulu. Il faut donc tester autre chose qu’une connexion normale : congestion, perte de paquets, interruption, rétablissement et changement de route peuvent modifier le comportement. Une démonstration réussie dans une salle bien connectée ne suffit pas à valider un déploiement dans un atelier, un espace d’essai mobile ou un site à couverture inégale.

Que doit faire le robot si la connexion tombe ? Il ne doit pas rester suspendu à une réponse distante pour une fonction qui exige une réaction sûre. Prévoyez un état de repli défini : interrompre l’action concernée, conserver une commande locale validée, demander une intervention ou passer dans un état sûr. Le choix dépend de l’analyse de risques et de la fonction considérée. Simulez la coupure pendant l’essai, puis vérifiez aussi le comportement au rétablissement : une ancienne réponse reçue tardivement ne doit pas être appliquée comme si elle était encore actuelle.

La confidentialité est un autre critère de placement. Une image, une carte de l’environnement, un état de robot ou une consigne peuvent révéler des informations sur le site et les opérations. Avant d’activer le transfert, établissez quels champs quittent le laboratoire, qui peut les consulter, combien de temps ils sont conservés et comment ils sont supprimés. Réduire les données envoyées ou traiter localement les images non nécessaires peut être préférable à leur transfert systématique.

Côté sécurité, documentez les identités autorisées, la protection des échanges, la gestion des secrets, les journaux d’accès et la procédure de révocation. Les recommandations de la publication du NIST sur les systèmes concernés peuvent servir de point de départ à une revue de sécurité, mais elles ne remplacent pas les règles de votre établissement ni l’examen de votre déploiement. Pour les communications protégées, la recommandation RFC 9325 sur l’usage de TLS fournit également une référence à examiner lors de la configuration des échanges.

Le calcul local et le calcul central répondent à des besoins différents

L’inférence embarquée réduit la dépendance à la liaison distante, mais elle doit tenir dans les ressources réellement disponibles et cohabiter avec les fonctions du robot. Le modèle, son format, le moteur d’inférence, les pilotes et les contraintes thermiques peuvent tous modifier le résultat. Ne transposez pas un benchmark obtenu sur un autre matériel au G1 : mesurez votre modèle sur la cible prévue et consignez la configuration.

À l’inverse, un service centralisé facilite la gestion d’un modèle commun, la comparaison d’expériences et l’allocation de ressources entre tâches. Il peut aussi simplifier la mise à jour de modèles lourds. En contrepartie, il introduit des dépendances d’accès, de réseau, de sécurité et d’exploitation. La facilité de déploiement ne signifie pas que le robot pourra continuer à fonctionner de manière sûre quand le service devient indisponible.

Pour cadrer le budget, séparez les postes au lieu de comparer seulement le prix d’une machine : matériel ou location, stockage des données, transfert, entretien logiciel, surveillance, sauvegardes et temps de l’équipe. Si vous lancez plusieurs essais, notez aussi les ressources mobilisées simultanément et le temps nécessaire pour reproduire un résultat. Ce sont des coûts mesurables, mais leurs valeurs doivent venir de vos propres devis et relevés.

Critère	Exécution sur le robot	Exécution distante
Continuité sans réseau	Peut être conservée pour les fonctions locales validées.	Dépend de la liaison, sauf mécanisme local de repli.
Ressources de calcul	Limitées par le matériel disponible et les autres tâches embarquées.	Peuvent être ajustées centralement, selon l’infrastructure effectivement accessible.
Mise à jour et comparaison	Exige de gérer les versions et les essais sur la cible.	Peut simplifier les essais partagés, avec une dépendance au service et à la connexion.
Données sensibles	Le traitement peut rester sur site, selon la configuration.	Le transfert et la conservation doivent être explicitement maîtrisés.
Exploitation	Nécessite de suivre l’état logiciel et les ressources embarquées.	Ajoute la supervision du réseau, des accès, des coûts et de la disponibilité distante.

Une architecture mixte sépare les fonctions sans promettre une compatibilité

Pour de nombreuses équipes, le bon choix n’est pas une migration intégrale. Une répartition possible consiste à laisser les boucles de mouvement et les fonctions de sécurité sur le robot, à exécuter localement les perceptions qui déclenchent une réaction immédiate, puis à réserver le calcul distant aux tâches de planification tolérantes au délai, à l’analyse différée ou à la comparaison de modèles.

Cette proposition reste une hypothèse d’architecture. Elle dépend des interfaces disponibles, du logiciel installé, de l’accès aux données, des ressources matérielles et de la manière dont les résultats peuvent être transmis au système. Consultez la documentation officielle et vérifiez chaque interface avec un essai isolé avant d’intégrer une décision distante dans le fonctionnement réel. Ne déduisez pas d’une page produit qu’un modèle, un pilote ou un mécanisme de commande précis est pris en charge.

Quelles tâches de contrôle doivent rester sur le robot ? Toute fonction dont le retard ou l’absence peut compromettre une réaction immédiate ou une mise en sécurité doit rester dans un chemin local validé, à moins que votre analyse et vos essais ne démontrent une autre solution sûre. Les fonctions de commande du mouvement ne doivent pas dépendre par défaut d’un aller-retour réseau. Le détail doit être établi à partir de l’architecture réelle et de la documentation des interfaces, pas d’une règle universelle.

Pour l’inférence robotique, votre répartition peut évoluer : commencez par une fonction non critique, vérifiez ses données et ses délais, puis élargissez seulement si le comportement reste reproductible. Une tâche de synthèse ou d’annotation vidéo, par exemple, se prête mieux à une exécution différée qu’une détection utilisée immédiatement pour modifier une trajectoire. Cette distinction est utile aux équipes qui travaillent aussi sur des flux audio ou vidéo : la valeur d’un modèle ne justifie pas à elle seule de le placer dans une boucle de commande.

Une décision vérifiable passe par un essai limité et réversible

Avant un essai, fixez la tâche exacte, le modèle, la version logicielle, les entrées, la cible d’exécution et les critères d’acceptation. Gardez ces éléments identiques entre le test local et le test distant. Sans cela, une différence de réussite peut provenir du modèle ou des données, et non de l’emplacement du calcul.

Procédez ensuite ainsi :

Relevez la chaîne actuelle, du capteur à l’action, et marquez les fonctions qui doivent continuer en cas de perte réseau.
Lancez un essai local de référence et consignez le taux de réussite, les temps de bout en bout, l’usage des ressources et les erreurs observées.
Déplacez uniquement une fonction non critique vers l’environnement distant ; ne changez pas simultanément le modèle et le chemin de commande.
Répétez la tâche dans des conditions de réseau normales, dégradées et interrompues. Mesurez le délai de repli et contrôlez le comportement après reconnexion.
Comparez les données transférées, les droits d’accès, les frais d’exploitation et le temps de maintenance, en plus des résultats techniques.
Conservez une procédure de retour à l’exécution précédente, avec versions et paramètres documentés. N’élargissez le déploiement qu’après validation de l’équipe responsable.

Comment déployer l’inférence robotique sans rendre le robot dépendant du réseau ? Gardez la commande critique et le comportement de repli dans le chemin local, puis limitez l’appel distant aux fonctions dont l’absence n’empêche pas l’arrêt sûr ou la poursuite contrôlée de la tâche. Le mode dégradé doit être testé, pas seulement décrit dans un document.

Décidez selon les résultats observés

Si une interruption réseau empêche une fonction de mouvement ou de sécurité de répondre, gardez cette fonction sur le robot et ne poursuivez pas le déploiement distant dans son chemin critique.
Si le résultat doit servir avant que la scène change et que le réseau produit des retards variables, choisissez l’exécution locale, sauf validation formelle d’une architecture différente.
Si la tâche est différée, centralisée et tolérante aux interruptions, évaluez le cloud en mesurant la latence complète, les transferts, les accès et le coût d’exploitation.
Si la charge dépasse les ressources locales mais que certaines fonctions doivent rester autonomes, adoptez une répartition mixte avec repli local vérifié.
Si vous n’avez pas encore mesuré la coupure, la reconnexion et le retour à l’état sûr, ne considérez pas le test nominal comme une autorisation de déploiement.

Consignez le résultat comme un choix lié à une tâche et à une configuration précises. Une mise à jour du modèle, de la connexion, du logiciel ou du matériel peut modifier l’évaluation ; prévoyez alors de répéter les essais pertinents.

En pratique, conserver toutes les expérimentations sur un poste local peut mobiliser l’équipe pour maintenir le système, gérer les versions et partager les ressources ; déplacer tout le calcul vers un service distant ajoute une dépendance réseau, des transferts de données et des vérifications d’accès. Pour compiler, comparer des modèles ou préparer des analyses sans en faire le contrôleur temps réel du G1, la location d’un Mac auprès de Hashvps peut être une piste à examiner si votre chaîne de développement est compatible avec macOS. Ce n’est pas un substitut au calcul embarqué ni une promesse de compatibilité avec vos outils : vérifiez d’abord vos besoins et les conditions indiquées dans la présentation de Hashvps et son centre d’assistance. Si votre travail exige une connexion matérielle directe au robot ou une charge continue proche de la commande, gardez une machine adaptée sur site ; si vous cherchez plutôt un environnement temporaire pour développer ou analyser, comparez cette option à votre poste actuel avant de vous engager.