microduck_rl 2b25a48. Aucune exportation de point de contrôle, exécution de GPU ou déploiement physique n'a été effectuée par ce site. Les commandes ci-dessous fonctionnent sur votre propre point de contrôle et écrivent des fichiers locaux.Sachez ce que représente chaque fichier.
| Artefact | Objectif |
|---|---|
| Point de contrôle d’entraînement (.pt) | État d’entraînement enregistré utilisé par l’exportateur correspondant. Conservez la configuration de la tâche et de l’entraînement avec lui. |
| Modèle exporté (.onnx) | Graphique d'inférence. Le parcours officiel d’exportation comprend la normalisation des observations apprises lors de l’entraînement. |
| Ensemble de politiques | Un modèle, un manifeste et un README décrivant comment le runtime doit l'utiliser. La réussite des contrôles de colis n'établit pas la qualité de la marche ou la sécurité du matériel. |
Une politique prend une observation — l'état attendu du robot et les valeurs de commande — et renvoie des actions. Le contrat partagé actuel compte 61 valeurs d'observation et 14 actions. Leur ordre et leur signification comptent autant que leur nombre. Démarrage rapide et registre des tâches MicroDuck RL ↗.
Exportez le point de contrôle avec sa tâche correspondante.
Utilisez l’environnement configuré à partir de votre exécution d’entraînement. Remplacez l'exemple de chemin de point de contrôle par le fichier réel que vous avez enregistré. L'ID de tâche suivant concerne l'exemple de marche ; utilisez la tâche qui a produit votre point de contrôle. Conservez un first-walk.onnx existant ailleurs si vous avez besoin de le préserver.
uv run scripts/export.py Mjlab-Velocity-Flat-MicroDuck \
--checkpoint-file /absolute/path/to/model_3000.pt \
--num-envs 1 \
--onnx-file first-walk.onnxIl s'agit de l'exportateur de projet, pas d'une commande de conversion générique. Il construit l'environnement d’entraînement et exporte l'acteur avec son normalisateur. Voir un mouvement plausible dans play ne vérifie pas qu'un modèle converti manuellement contient ce normalisateur. Vérifiez le message d'achèvement de l'exportateur et le fichier de sortie réel. Exportateur officiel ONNX et normalisation des observations ↗.
Répétez le fichier exporté avec la bonne mise en page.
uv run scripts/infer_policy.py \
--walking first-walk.onnx \
--new-cmd-obsLe spectateur imprime la forme d’entrée du modèle de marche. Le drapeau ci-dessus sélectionne la disposition actuelle des commandes. Les anciennes politiques à 51 entrées en ont besoin. Ne complétez pas un modèle arbitraire pour faire correspondre les dimensions : cela ne répare pas les différentes significations d'observation, l'ordre conjoint, le timing ou la mise à l'échelle des actions. Le script local utilise l'inférence CPU ONNX, mais a toujours besoin de ses dépendances Python, des actifs de modèle et d'un visualiseur fonctionnel. Indicateurs de lecture locale et commandes du clavier ↗.
| Action | Simulateur de navigateur | Infer_policy.py local |
|---|---|---|
| Assis/debout | R en mode pieds | Y avec la politique assis/debout correspondante chargée |
| Coup de pied gauche/droit | Q/E en mode pieds | K/L avec des politiques de kick chargées |
| Roulement vers l'avant | R est assigné à s'asseoir/debout | R uniquement lorsqu'une politique de roulade est fournie |
Les actions facultatives nécessitent leurs fichiers de modèle correspondants. La commande de marche uniquement ci-dessus ne charge pas les politiques de position assise, de coup de pied ou de roulis. Pour le mappage actuel du navigateur, utilisez le guide du simulateur.
Inspectez un colis avant de le partager.
L'éditeur dispose d'un mode d'exécution à sec qui met en scène un package local. Remplacez YOUR_USERNAME par l'espace de noms Hugging Face prévu. Cet exemple décrit une politique de marche perpétuelle ; n'utilisez pas cette sémantique pour une astuce sans rapport.
uv run publish --onnx first-walk.onnx \
--repo YOUR_USERNAME/microduck-first-walk \
--kind perpetual --slot walk --dry-runL'éditeur vérifie la forme attendue, exécute une vérification de sortie de base et valide le manifeste avant de mettre en scène policy.onnx, manifest.json et README.md. L’exécution à sec s’arrête avant le téléchargement du Hub. Il recrée son dossier intermédiaire local publish-first-walk/, conservez donc les notes manuelles en dehors de ce dossier. Conditionnement, validation et mise en œuvre de la politique à blanc ↗.
Une sortie de modèle finie et non constante n’est qu’un contrôle de validité de base. Avant toute tentative matérielle, documentez ce qui s'est passé dans la simulation lors du démarrage, de l'arrêt, du virage et de la récupération. Conservez la documentation d'exécution du robot et votre configuration exacte à côté de ces observations.
Gardez la provenance attachée au résultat.
Dépôt original et révision complète :
Identifiant de tâche et configuration d’entraînement :
Fichier checkpoint ou URL d’exécution :
Commande d’export exacte :
Nom du fichier ONNX et SHA-256 :
Dimensions d’entrée/sortie et format des commandes :
Commande d’exécution et modèle du robot :
Échelle des actions et fréquence de contrôle :
Comportement observé en simulation :
Échecs connus et cas non testés :
Validation matérielle éventuelle :
Auteur original, source et références de licence :Pour une stratégie personnalisée, enregistrez sa source et ses autorisations séparément des maillages de robots, de la musique ou d'autres ressources groupées. Un résultat de simulation doit rester étiqueté comme simulation lorsque vous le partagez.
Continuez avec votre résultat.
Qu’aimeriez-vous comprendre ensuite ?
Gardez la source, votre environnement et vos observations ensemble.
Sources et date de vérification
Sources vérifiées le 8 septembre 2026 · Source examinée