Pourquoi ACT excelle dans les tâches bimanuelles
ACT (Action Chunked Transformers) a été initialement développé spécifiquement pour la recherche sur la manipulation bimanuelle. Son idée centrale – selon laquelle la prévision de séquences d'actions futures (morceaux) plutôt que d'actions en une seule étape réduit les erreurs de composition – est particulièrement utile pour les tâches bimanuelles, où une petite erreur dans la trajectoire d'un bras peut provoquer un échec en cascade dans l'exécution de l'autre bras.
Le mécanisme de segmentation des actions donne effectivement à la politique un horizon de planification. Au lieu de s'engager sur une seule commande conjointe à chaque pas de temps de 50 Hz, ACT planifie 100 étapes à l'avance et facilite l'exécution. Pour une tâche de transfert, cela signifie que la politique peut « voir » l'approche des deux bras vers le point de transfert dans le cadre d'une séquence planifiée, plutôt que de réagir indépendamment à chaque image. Empiriquement, cela réduit de moitié le taux d'échecs en cours de transfert par rapport aux approches non fragmentées sur des ensembles de données bimanuels.
Une mise en garde : ACT suppose que les démonstrations de votre ensemble de données représentent un stratégie cohérente. Si différentes démos montrent des manières fondamentalement différentes d'exécuter le transfert – un bras différent qui initie, une hauteur de transfert différente – le composant CVAE aura du mal à coder un style unique. Vos 100 démos doivent toutes exécuter la même stratégie de mouvement.
Commandement de l'entraînement
--device cuda flag si vous avez un GPU. Les options Cloud GPU (Lambda Labs, Vast.ai) coûtent environ 0,50 à 1,50 $/h pour le matériel nécessaire.
Lecture des courbes d'entraînement bimanuelles
Les courbes d'entraînement bimanuelles diffèrent de celles à un seul bras sur un point important : vous disposez de deux espaces d'action et la politique doit apprendre à les coordonner. Surveillez ces modèles dans vos courbes de perte (voir dans TensorBoard à l'adresse tensorboard --logdir ~/dk1-policies/):
L_reconstruction (perte globale d'action)
Devrait diminuer de ~3,0 à moins de 0,4 de 60 000 étapes. Un plateau supérieur à 0,7 après 40 000 étapes indique des problèmes de qualité de l'ensemble de données – probablement une trop grande variance dans le moment ou la position du transfert.
L_kl (régularisation CVAE)
Commence près de 0 et monte lentement jusqu’à 5–15. S'il dépasse les 30, la CVAE peine à trouver un intégration de style compact. Cela signifie souvent que vos manifestations comportent trop de diversité comportementale. Envisagez d'éliminer les 20 % de démos les moins cohérentes et de les recycler.
Erreur d'action : gauche contre droite
Si vous activez la journalisation des erreurs d'action par bras (via le training.log_per_action_dim=true override), vous verrez des courbes de perte distinctes pour les dimensions d'action gauche et droite. Un écart important et persistant entre les deux indique que les démonstrations d'un bras sont plus cohérentes que celles de l'autre — consultez votre liste de contrôle de qualité de l'unité 4 pour le bras en retard.
Hyperparamètres spécifiques au bimanuel
| Paramètre | Par défaut (un seul bras) | DK1 Bimanuel Recommandé | Pourquoi |
|---|---|---|---|
action_dim |
7 | 14 | Deux bras 6-DOF + 2 pinces = 14 dimensions d'action |
chunk_size |
100 | 100 | Idem : le regroupement des actions est déjà bien adapté aux délais de coordination bimanuels |
dim_feedforward |
3200 | 3200 | Aucun changement nécessaire : l'espace d'action plus grand est géré par la tête d'action, et non par la largeur du transformateur. |
num_steps |
50000 | 80000 | La coordination bimanuelle nécessite davantage d'étapes de formation pour converger de manière fiable ; 80 000 est le minimum pratique pour 100 démos |
batch_size |
32 | 16 | Réduit pour s'adapter aux plus grands échantillons d'ensembles de données bimanuels (flux de caméra double) dans la mémoire GPU |
kl_weight |
10 | 10 | La valeur par défaut fonctionne bien ; augmenter à 20 seulement si L_kl reste proche de zéro après 30 000 pas (CVAE n'apprend pas) |
Sélection du point de contrôle
Enregistrez des points de contrôle tous les 5 000 pas (training.save_freq=5000). Ne présumez pas que le point de contrôle final est le meilleur. Les politiques bimanuelles peuvent être surajustées à un nombre de pas élevé : la politique apprend à reproduire parfaitement les démonstrations de formation mais perd sa généralisation face aux légères variations du monde réel que vous rencontrerez lors de l'évaluation.
Sélectionnez le point de contrôle à l'étape où L_reconstruction atteint son minimum avant de commencer à se stabiliser ou à légèrement augmenter. Cela se situe généralement entre 60 000 et 80 000 étapes pour des ensembles de données bimanuels de 100 démos. Déployez deux points de contrôle (le point de contrôle à perte minimale et le dernier) et comparez leurs performances réelles dans l'unité 6.
Unité 5 terminée quand...
La formation a complété 80 000 étapes et les points de contrôle sont enregistrés à ~/dk1-policies/cube-handoff-v1/. La finale L_reconstruction la valeur est inférieure à 0,5. Vous avez identifié votre meilleur point de contrôle en fonction des courbes de perte. Vous comprenez pourquoi la courbe L_kl se comporte comme elle le fait lors de votre exécution. Vous êtes prêt à déployer sur du matériel réel dans l'unité 6 : le taux de réussite cible du transfert du cube est > 60 % (le bimanuel est plus difficile qu'un seul bras, et il s'agit d'un bon résultat de première exécution).