Réplique MicroDuck 20261023c : IMU et étalonnage

Image actuelle : 20261023c, publiée le 23 octobre

L'auteur a marqué 20261023c draft=false, prerelease=false, publié 2026-10-23 07:36:28 UTC (15:36:28 Pékin). Il s'agit du statut de sortie de la réplique personnelle, et non d'une version officielle du démon Pollen ou d'un test d'acceptation physique terminé. Le précédent 23b a été publié à 04:58:14 UTC et est désormais historique.

Utilisez microduck-replica-20261023c.img.xz avec sa somme de contrôle correspondante : 712 068 864 octets, SHA-256 10009c0a4aa963900719649836f5544036ad52cc15e3a0228eef05f6b747dab5. Téléchargez-le auprès de l'auteur, conservez une carte de travail connue et votre propre sauvegarde de configuration, et suivez la première utilisation de. Nous avons vérifié les cinq petites pièces jointes par rapport à leurs résumés API ; la taille/le hachage de l'image sont les valeurs de l'éditeur. Nous n’avons pas téléchargé, décompressé ou flashé la grande image.

shasum -a 256 -c microduck-replica-20261023c.img.xz.sha256

Manifeste : Studio/build dd7a753026c40b0bf385374a896e7253cff42720 ; environnement d'exécution 0791fcd44f71c705dc8bb0fbcde405593b52d19b, build 4734cbb-feetech-imu-auto-control.44 ; robot SHA-256 edf182edb7bf11aeeeedfdab98170ab2ec48a9ec18417f9b68c744b0a60c6d16 ; assistant 0.7.1. Contrairement à image23, le runtime a changé. Cela reste la pile HD1910 personnalisée, et non la version 0.17.8 officielle.

La détection atteint maintenant le programme de mouvement

L'enregistrement de compatibilité fixe distingue Feetech ID200, block56/15 ; DXL2 ID200, bloc SFLP 124/12 ; et I²C BNO08x/LSM6DSV16X existant. [bus] imu_protocol est par défaut auto, avec des remplacements feetech / dxl2. Les lectures de sonde ne réécrivent pas les identifiants, les débits en bauds ou l'EEPROM. Une IMU arbitraire avec une disposition de données différente n'est pas prise en charge par son seul nom.

Studio signale le protocole et la disposition détectés. L'ancienne approbation de montage Feetech ne peut pas autoriser le couple DXL2. Le changement de module physique ou le montage nécessite également un nouvel étalonnage. Le runtime/helper correspondant, le protocole affiché et la vérification de montage vont de pair ; utilisez les distinctions d'étalonnage étape par étape.

Ce que l'auteur a vérifié et ce qui reste ouvert

L'auteur rapporte des contrôles d'image/hors ligne et une simulation en série. Un test hôte a utilisé l'implémentation originale du protocole C de ScrapMeta par rapport au lecteur Rust réel : 7 cas de conformité, et non sept cartes. La référence du firmware db04d323 cible une carte STM32G031F8P6 + LSM6DSV16X particulière et possède sa propre licence MIT ; l'image SD ne fait pas clignoter ce MCU. Les lectures soutenues sur la carte réelle, l'étalonnage, la position debout et la marche restent en attente. Le contrat du micrologiciel ScrapMeta épinglé utilise 1 Mbps ; le protocole de correspondance ne valide pas le brochage d’une autre carte.

Le compte rendu signale aussi 17 échecs préexistants de tests unitaires robotd, sur l’ancienne comme sur la nouvelle base ; il ne prétend pas que tous les tests Rust réussissent. La caméra conserve une source de test par défaut ; le contrôle automatique des services caméra/ToF et la validation avec des capteurs réels restent à terminer. Distinguez ces limites du statut de publication formelle. Les restrictions de distribution personnelle et non commerciale des modèles inclus restent applicables. La procédure de paquets de modèles ci-dessous reste pertinente ; l’ancien inventaire des composants d’image23 est replié dans l’historique.

shasum -a 256 -c microduck-replica-20261023.img.xz.sha256

Get-FileHash -Algorithm SHA256 .\microduck-replica-20261023.img.xz

Les nouvelles pages de modèle ne déplacent pas l’entraînement sur le robot

La entraînement et l'exportation s'effectuent sur l'ordinateur. Studio gère désormais les modèles importés, les utilisations sélectionnées et les affectations de boutons d'action. Pour l'entrée réellement prise en charge, suivez le guide détaillé d'importation de modèle : un package contenant le modèle et ses manifestes/contrats correspondants, plutôt que de traiter un simple fichier ONNX comme compatible. Consultez le package et la liste de contrôle de changement avant l'importation. Installé, sélectionné et en cours d'exécution sont trois états différents.

Recalibrer une direction IMU déjà enregistrée avec une session récupérable

Un quaternion enregistré ne masque plus l'itinéraire d'étalonnage grossier d'origine. Le nouveau flux nécessite Studio et helper/sudoers 0.7.0 ensemble. Commencez avec le corps soutenu et relâchez le couple ; utilisez « Recalibrer la direction » et sa deuxième confirmation. En mode mouvement, l'assistant entre temporairement en mode d'étalonnage ; une session d'étalonnage en usine réutilise son itinéraire existant. Ne remplacez pas cette transaction par une modification en mode manuel.

Capturez l'immobilité, puis l'inclinaison du torse vers l'avant demandée. Remettez physiquement le robot à la verticale avant de commencer la vérification de l'exécution, et inclinez-le à nouveau vers l'avant lorsque vous y êtes invité. L'achèvement nécessite la relecture de l'IMU actuelle, la nouvelle direction et le nouveau mode d'installation. Les zéros conjoints, les directions et les limites sont conservés ; le mode d'origine revient avec le couple toujours désactivé. L'annulation, l'actualisation ou une interruption doivent être gérées via l'entrée de récupération jusqu'à ce que la session soit résolue. Les tests locaux de l’auteur remplacent la frontière de service privilégiée ; une mise à jour, une annulation et un redémarrage de la carte réelle nécessitent toujours l'acceptation du matériel.

Le service de caméra en ligne ne constitue pas une preuve d'une image de caméra

La nouvelle implémentation caméra/ToF ajoute des contrôles de source vidéo, une grille de distance 8×8, un nombre de zones valides et des lectures les plus proches/les plus éloignées. Vérifiez si les données sont déconnectées, erronées, obsolètes ou simulées. Les sept indicateurs d’appareil de l’aperçu incluent la batterie, les servos, l’IMU, l’appareil photo, le ToF, la manette de jeu et la carte. Ce sont des états de diagnostic, et non sept tests matériels réussis.

Cette image est toujours par défaut une image de test de la caméra. Un bonjour de service multimédia ou une entrée de configuration n'établit pas de véritable flux de caméra, et une unité de service ToF n'établit pas de portée valide. L'ouverture de ces pages d'état en lecture seule ne démarre pas les services ; le démarrage automatique unifié dépendant du matériel reste inachevé. Les vérifications réelles de la caméra/ToF et la séquence complète de premier démarrage/debout/marche de cette image sont toujours en attente. Les notes précédentes sur le réseau vérifié à la source, SSH et bus-IMU ci-dessous restent utiles dans le cadre de leur portée indiquée.

Premier démarrage : le point d'accès d'abord, puis l'adresse de votre appareil

Sur une nouvelle carte sans réseau enregistré, le moniteur réseau révisé ouvre le point d'accès immédiatement après avoir détecté la déconnexion au lieu d'attendre 45 secondes. Rejoignez Microduck-xxxx, ouvrez http://10.42.0.1:8000/ et utilisez Studio pour choisir le réseau domestique. Le mot de passe du hotspot publié est microduck ; ce n'est pas un mot de passe SSH.

Après les modifications Wi-Fi, Studio tente de localiser la nouvelle adresse. Les itinéraires des appareils de l'auteur sont Windows http://duck-xxxx:8000/, Apple http://duck-xxxx.local:8000/ et Android l'adresse IP affichée par votre routeur. Remplacez xxxx par votre nom d'hôte actuel. Si la redirection échoue, vérifiez d'abord que le téléphone/ordinateur et le robot sont sur le même réseau local et essayez cette adresse IP. La route Windows résout le problème Clash / .local de l'auteur ; cela ne justifie pas la modification des paramètres à l’échelle du routeur.

SSH est facultatif ; enregistrez votre propre clé publique

Les nouvelles instructions Studio placent l'accès de récupération sous Plus → SSH. Définissez d'abord un mot de passe de connexion au Studio. Vous pouvez enregistrer votre propre clé publique OpenSSH ou définir délibérément votre propre mot de passe SSH pour activer l'accès par mot de passe. L'image ne contient aucune clé de connexion d'auteur et il n'y a aucun mot de passe SSH distant par défaut utilisable. Collez la ligne .pub, jamais une clé privée. L'analyseur de clé et l'assistant implémentent ce chemin. Un mot de passe Studio et le mot de passe SSH/sudo configuré séparément servent à des fins différentes.

Sauter une étape de la liste de contrôle ne la valide pas

La liste de contrôle révisée autorise les étapes ignorées et corrige un double-clic qui pourrait atterrir sur Terminé. Enregistrez exactement ce qui a été ignoré. Ignorer l'orientation de l'IMU utilise une hypothèse de montage par défaut ; il ne mesure pas votre installation. En mode d'étalonnage, « position de support » maintient les articulations sans contrôle de l'équilibre. Soutenez le robot et désactivez le maintien avant de valider la configuration. L'auteur n'a pas terminé la séquence d'acceptation position debout/saut → validation → paire → marche ; ne considérez pas un redémarrage ou un bouton activé comme une vérification réussie. Voir l'implémentation du commit.

Bus IMU : un dossier de banc daté, pas une acceptation complète du robot

L'enregistrement de validation du micrologiciel 1.0.0 récemment téléchargé est daté de septembre 2026. Il rapporte des tests FT-SCS à 1 Mbps avec les servos 2 et 3 plus l'ID IMU 200. La mise en place de l'IMU a d'abord renvoyé 3/30 ; le mettre en dernier retour 30/30. L'auteur nécessite l'ID 200 après les servos, ou dans son propre groupe de lecture. Il s'agit d'un résultat de banc d'auteur spécifique, pas de notre test ou de notre preuve sous les 15 servos. L’intégration du corps entier, le fonctionnement de longue durée et la séquence IMU de nouvelle image restent en dehors de cette preuve.

L'auteur rapporte une entrée réussie en mode d'étalonnage, une lecture Studio servo/IMU, un accès avec Clash en cours d'exécution et un démarrage du service SSH. L’acceptation complète du mouvement de nouvelle carte reste incomplète. Si vous collectez un échec existant, enregistrez l'image exacte, les versions Studio/runtime, l'étape de la liste de contrôle et l'erreur expurgée nécessaire ; exporter les diagnostics en privé plutôt que de publier un ensemble complet. Les contrôles CAO/BOM antérieurs à six plaques restent un sujet distinct pour les fichiers d'impression ci-dessous.

shasum -a 256 -c microduck-replica-20261021b.img.xz.sha256

Get-FileHash -Algorithm SHA256 .\microduck-replica-20261021b.img.xz

shasum -a 256 -c microduck-replica-20261020.img.xz.sha256

Get-FileHash -Algorithm SHA256 .\microduck-replica-20261020.img.xz

py -3.13 -I dev/fake_robotd.py --fixture tests/fixtures/now-20261018.jsonl --mode commissioning --calib factory --net-mode hotspot --net-state-file ./state-dev/net.json

py -3.13 -I run.py --listen 127.0.0.1:18080 --robotd tcp:127.0.0.1:17001 --configd tcp:127.0.0.1:17002 --net-state ./state-dev/net.json --dev-autologin --state-dir ./state-dev --log-dir ./logs-dev

py -3.13 -I dev/fake_robotd.py --fixture tests/fixtures/now-20261018.jsonl

py -3.13 -I run.py --listen 127.0.0.1:18080 --robotd tcp:127.0.0.1:17001 --configd tcp:127.0.0.1:17002 --dev-autologin --state-dir ./state-dev --log-dir ./logs-dev

python3 -I run.py --selfcheck

python3 -I run.py set-password

Examen des sources : 16 octobre 2026. La dernière révision du projet fanhao375 est 2b734d5 ; la révision CAD README indépendante est 1214bc6, tandis que le 3MF de fabrication reste à l'instantané source précédent. Les résultats de construction, de banc et de caméra ci-dessous sont rapportés par leurs auteurs. Nous n’avons pas imprimé, flashé ou exploité ce matériel. Aperçu du projet ↗.

Choisissez d'abord la version servo et CAO

Le projet sépare l'itinéraire Feetech HD-1910 physiquement assemblé d'un itinéraire XL330. L'enregistrement de construction ↗ relie l'assemblage des 15 servos et les séquences de posture ; se lever et s'asseoir démontrent ces mouvements, pas un contrôleur de marche qualifié. Utilisez le pointeur du fichier d'impression actuel ↗ pour atteindre 机械行者Le référentiel CAO de Robo ↗. Ses versions vérifiées sont HD-1910 v2.1 et XL330 v1.1 ; les pièces d'accouplement des cornes diffèrent. Les maillages de simulation plus anciens laissés dans le référentiel de répliques principal ne sont pas des substituts prêts à la fabrication.

Projet d'impression du 30 septembre : inspecter les matériaux et le support de la caméra

Le référentiel contient désormais microduck-飞特版-BambuStudio2026-09-30.3mf ↗. L'inspection directe de ses métadonnées ZIP de Bambu Studio a trouvé quatre objets source 合体轮胎.STEP et aucun ancien nom de source de jante/pneu séparé. Le projet enregistré contient deux préréglages de filament, tous deux PLA. La correction de la nomenclature de l'auteur ↗ indique que les pneus combinés, la mâchoire souple et le dessus de la bouche souple nécessitent TPU. Définissez les matériaux objet par objet avant de les découper ; le PLA par défaut du projet n’est pas une instruction imprimable pour chaque pièce. Cette inspection du fichier n’établit pas l’ajustement, la résistance ou une impression réussie.

Le même projet intègre un simple face_part_面部零件.stp ; il n'inclut pas et non la variante ultérieure face_part-FT1 dont l'espacement des trous a été modifié pour la caméra Radxa d'origine. Obtenez la version STEP v2.1 des pièces modifiées séparée ↗ si ce support de caméra correspond à votre nomenclature. Le Cahier d'assemblage du 29 septembre ↗ contient 33 catégories de pièces imprimées et 21 catégories de pièces achetées avec des liens d'achat, et non une quantité de 54 pièces ou un coût de livraison vérifié. Choisissez la variante à pied ou à rouleau en option avant de compter les impressions. Le CAD README mentionne toujours le 3MF remplacé le 15 septembre ; le dossier engagé du 30 septembre constitue la preuve de cette correction.

Ce que montrent réellement les tests au banc et par caméra

• Le enregistrement de feedback du 28 septembre ↗ rapporte 14 articulations maintenues dans une pose, 3 000 échantillons valides chacune, environ 63,99 secondes au total et environ 46,87 Hz observés par rapport à une cible de 50 Hz. Le servo de bouche a été exclu ; les objectifs n’ont pas été modifiés. Aucune nouvelle erreur de délai d'attente/ID/somme de contrôle dans cette fenêtre ne résout les erreurs dans d'autres exécutions, et il ne s'agissait pas d'un échantillonnage IMU, d'une inférence de politique ou d'une écriture de mouvement.
• L'enregistrement de la caméra ↗ rapporte un court test de 40 images 1920×1080 après correction du câble sur Radxa Bookworm B1. Il ne valide pas un débit soutenu ni l’image Armbian distincte du projet.

Calibrez chaque joint HD-1910 avec le nouvel outil source

Le changement d'outil HD1910M ↗ du 11 octobre ajoute zero (étalonnage de position 0x0B), reboot (0x08), entrée de degré pour limits et vérifications de plage pour les écritures différées. Construire à partir du manifeste Cargo engagé ↗ ; son nom binaire est feetech-HD1910M-tester. Remplacez PORT et SERVO_ID par le périphérique série réel et l'ID commun. L'ID par défaut est 1, ce qui peut être le mauvais joint sur un robot assemblé. Soutenez le joint, gardez un autre contrôleur hors du bus et inspectez le câblage et le guide d'alimentation de l'auteur du ↗ avant de le mettre sous tension.

cd tools/FeeTech_HD1910M_Servo
cargo build
./target/debug/feetech-HD1910M-tester -p PORT -i SERVO_ID get pos
./target/debug/feetech-HD1910M-tester -p PORT -i SERVO_ID get pos-offset
./target/debug/feetech-HD1910M-tester -p PORT -i SERVO_ID get min-angle
./target/debug/feetech-HD1910M-tester -p PORT -i SERVO_ID get max-angle
./target/debug/feetech-HD1910M-tester -p PORT -i SERVO_ID torque off
# Hold this joint at its intended mechanical zero.
./target/debug/feetech-HD1910M-tester -p PORT -i SERVO_ID zero
./target/debug/feetech-HD1910M-tester -p PORT -i SERVO_ID get pos
./target/debug/feetech-HD1910M-tester -p PORT -i SERVO_ID get pos-offset

zero déverrouille l'EPROM, applique l'étalonnage, la reverrouille et relit la position plus le décalage. Son code rejette une position à plus de quatre chefs d'accusation de la cible demandée ; il ne pas compare le décalage avec la valeur de pré-changement pour vous. Enregistrez les deux lectures avant d’effectuer le changement persistant. N'exécutez pas cet étalonnage à un tour en mode multi-tours. Le didacticiel et la CLI diffèrent par leur brève formulation de restauration de couple, n'activez donc pas aveuglément le couple sur un joint suspendu : vérifiez le résultat et utilisez la procédure source actuelle pour votre assemblage pris en charge.

Utilisez limits MIN_DEG MAX_DEG --deg uniquement après avoir dérivé une plage de sécurité pour cette articulation ; sans --save, c'est temporaire. Ajoutez --save uniquement lorsque la plage a été vérifiée et doit persister. La CLI imprime les deux limites renvoyées mais ne les compare pas automatiquement avec les nombres demandés. Après un changement persistant, émettez reboot, attendez environ une seconde, puis relisez min-angle, max-angle, pos et pos-offset. Une commande de redémarrage sans réponse peut quand même avoir redémarré le servo ; les communications et relectures ultérieures vérifient la persistance, tandis qu'un marqueur SRAM serait nécessaire pour prouver le redémarrage lui-même. Le redémarrage n'annule pas un zéro enregistré. Si les valeurs précédentes ont été enregistrées, restaurez-les avec offset OLD_OFFSET --save et limits OLD_MIN OLD_MAX --save, puis redémarrez et relisez ; sinon, réalignez et recalibrez le zéro. Implémentation de la commande ↗.

Le rapport de l’auteur sur 15 servos ↗ indique le firmware 3.46 et les identifiants 10–14, 20–24 et 30–34. En position debout, les lectures de position s’écartaient de la cible de quatre unités au maximum. Son journal des modifications porte la date interne du 3 octobre, mais le fichier a été ajouté au dépôt le 11 octobre ; le manifeste indique encore la version 0.1.0 malgré un titre de journal en 0.2.0. Nous ne l’avons pas compilé et n’avons pas reproduit l’essai matériel. La séquence de lecture statique du 28 septembre, avec 14 articulations et 3 000 échantillons par articulation, n’écrivait aucune commande de mouvement. À lui seul, ce rapport sur 15 servos ne démontrait pas une boucle combinant IMU, inférence ONNX et commande du mouvement. L’auteur a ensuite rapporté un autre essai partiel en boucle fermée, le 12 octobre, décrit ci-dessous.

Lisez le guide en images avant de vous connecter pour la première fois

Les instructions de l'image ↗ corrigent la séquence de première connexion de la carte publique d'origine : complétez l'assistant de racine initiale Armbian avant d'attendre le compte canard normal, puis remplacez les valeurs par défaut. L'image du 20 septembre nécessite toujours la correction DHCP sans fil documentée ; le candidat du 29 septembre a passé les contrôles hors ligne mais n'a pas été flashé ni testé au démarrage comme cet artefact exact. Les deux sont des images de système d’exploitation de base, et non un environnement d’exécution intégré, une console d’asservissement ou une politique de marche. Faites correspondre la carte, l'image et la somme de contrôle Radxa Zero 3W V1.12 ; suivez les instructions d’alimentation USB/HAT séparées de la source.

Où s’inscrit la nouvelle référence d’entraînement

Le projet kissqy HD1910 actuel ↗ publie un firmware, un modèle et une pile de console de bureau distincts. Son précédent guide de version R1 ↗ et ses packages actuels peuvent désormais être comparés à votre propre matériel plutôt que traités comme un téléchargement futur. Son aperçu de la console en ligne utilise toujours des données simulées. L'ancienne ligne de base épinglée décrivait les limites préalables à la publication ; le nouveau résultat physique d'un robot ci-dessous provient d'une réplique distincte corrigée localement, ce qui ne prouve pas que chaque mouvement packagé fonctionne sur chaque version.

Image R1 publique : vérifiez le fichier et votre matériel

La version publique du 12 octobre ↗ comprend un actif microduck-zero3w-0.15.1-R1.img.xz réel et accessible de manière anonyme ↗ (767 412 924 octets). Son SHA-256 publié est 75da978b5d56acd9e4146256431732381de84523bb683e4ab7ac9f0580a7bce5 ; calculez votre propre hachage local après le téléchargement. La prose du corps de la version a un nom de fichier plus ancien, alors sélectionnez l'élément réel. Le guide de configuration épinglé ↗ indique de flasher l'image compressée en tant qu'image personnalisée dans Armbian Imager, puis de se connecter à Microduck-kissqy (mot de passe initial 12345678) et de terminer la configuration du Wi-Fi et du nouveau mot de passe de connexion, en utilisant http://10.42.0.1:8088 si la page captive ne s'ouvre pas. Les Windows R17 V164 ZIP ↗ et R1.5.27 ZIP ↗ sont des téléchargements à commit fixe distincts, et non des applications préinstallées sur votre ordinateur.

sha256sum microduck-zero3w-0.15.1-R1.img.xz
# On macOS, if sha256sum is unavailable:
shasum -a 256 microduck-zero3w-0.15.1-R1.img.xz

R1 utilise Microduck 0.15.1 officiel ainsi que la pile Feetech de kissqy. L'auteur rapporte un reflash zéro avec identification hotspot/Wi-Fi, SSH, robot-bus et R17, pas sur toutes les cartes ou démarches. La source IMU d'exécution publiée ↗ lit sa carte imu_to_dxl montée sur bus ; L'inspection d'image en lecture seule de l'auteur de la réplique ↗ n'a trouvé aucun chemin I2C de la carte mère BNO085 et a averti qu'une carte Zero 3W V1.12/AIC8800 particulière peut avoir besoin d'un chargeur de démarrage différent. L'auteur a ensuite démarré une carte R1 V164 sur cette machine V1.12 après avoir ajouté un chargeur de démarrage non publié et un correctif I2C-IMU ; La configuration du point d'accès et du Wi-Fi s'est ouverte, suivie d'un bref essai du modèle. Cela ne valide pas R1 non modifié sur cette carte. N'assimilez pas cette image aux anciennes images de base Armbian nues de l'auteur de la réplique ou au moteur d'exécution modifié localement utilisé dans l'essai ci-dessous. L'étalonnage de l'échantillon emballé doit être remplacé par les zéros des servos, les directions, les limites des articulations et le montage de l'IMU du robot réel avant le début ou le mouvement.

Nouveau résultat physique : IMU zéro, maintien de la politique, jambes alternées

Dans un premier rapport ↗ et un enregistrement nocturne du 12 octobre ↗, l'auteur de la réplique rapporte un robot HD1910 × 15 avec un BNO085 sur le bus I2C du Zero et un runtime kissqy R17 patché localement. Le HOME initial et un maintien de la politique pendant 10 secondes ont été suivis de chutes. La comparaison des angles d'articulation réels avec le MJCF officiel a révélé un décalage de montage de l'IMU en inclinaison d'environ 8,54° et en roulis d'environ 1,78° sur cette machine. Après correction, l'auteur rapporte une prise politique de 70 secondes sans chute et trois essais avec joystick au cours desquels les genoux alternaient ; le dernier essai de 6,3 secondes comportait environ 26 échanges. La distance vers l'avant n’a pas été mesurée parce que son odométrie est restée à zéro, il s'agit donc d'un premier mouvement partiel en boucle fermée, et non d'une marche soutenue mesurée. Les journaux bruts du robot n’ont pas été inspectés de manière indépendante ici.

Les étapes d'analyse publique ↗ montrent comment vérifier d'abord les signes d'axe, capturer une pose HOME stationnaire, comparer les angles de joint réels de cette construction avec le MJCF officiel et calculer sa propre correction de montage du capteur. Sauvegardez hd1910-calibration.toml, effectuez tout changement de support uniquement avec le couple coupé, redémarrez le service et répétez le contrôle statique avant le mouvement. Le quaternion de l'auteur et la valeur de 8,54° sont et non un étalonnage pour un autre assemblage. Un câblage intermittent de l'IMU, une chute de puissance et de la chaleur ont également été détectés dans cette version. Le runtime BNO085 corrigé localement ne fait pas partie du téléchargement public R1.

Diagnostic des exécutions courtes : alimentation, réglages du modèle et réponse des servos

Le rapport de l'auteur du du 13 octobre ↗ compare cette carte R1/V164 corrigée avec une ancienne carte R17 corrigée localement sur le même robot HD1910. Les deux ont perdu de la puissance sur toute la carte lors de courtes séries de modèles ; la dernière tension côté servo de la nouvelle carte était d'environ 3,9 V, et la vidéo et les journaux se sont terminés sans séquence d'arrêt. L'auteur soupçonne des transitoires d'alimentation ou de plomb, mais n'a pas encore mesuré les transitoires avec un oscilloscope ni vérifié une réparation. Ne lisez pas ceci comme un correctif logiciel ou une prescription de câblage testée. Enregistrez l'alimentation, la révision de la carte, le modèle et les dernières entrées de santé/journal sur votre propre version avant de répéter un test sous tension.

Le modèle combiné marche/chute dans ce rapport charge son propre deployment-execution.json. Pour ce modèle, la modification de l'échelle d'action ou des filtres robotd.toml n'a pas modifié les valeurs chargées : inspectez d'abord robot.busStatus.loaded_models.walk.runtime_execution_profile. Sur cette machine, les boîtiers D et de limite de couple de la console V164 n'affectaient pas non plus les servos, tandis que son ancienne configuration R17 utilisait un autre chemin. Les courts tests de l'auteur ont révélé moins de gigue haute fréquence après la modification simultanée de plusieurs réglages de servo, mais le jeu du pied est resté inférieur à sa simulation et certaines réponses se sont détériorées. Les scripts d'analyse publics ↗ montrent la méthode de mesure ; aucun gain, couple ou numéro IMU de ce robot n'est une recette de réglage réutilisable. Il n’y a toujours pas de distance mesurée vers l’avant ni de vérification de la marche soutenue.

Ce qui a changé après l'examen de la source V167 uniquement

kissqy V167/control.43 écrit toujours les valeurs fixes D=0 et limite de couple=1000 dans la RAM des servos à chaque activation du robot ; il ne les conserve pas en EEPROM et ne démontre pas un réglage arbitraire depuis l’interface graphique. L’auteur de la version n’a pas consigné d’essai physique de marche avec V167. Depuis, l’auteur de la réplique a installé son fork I2C distinct ↗ sur un robot HD1910, avec une BNO085 sur l’I2C4 du Zero, et a rapporté le 15 octobre des essais debout, de marche et de rotation. Ce résultat concerne ce fork et cet auteur ; il ne valide ni R1 d’origine ni kissqy V167 sans modification. Le fichier facultatif de paramètres des servos bénéficie de vérifications du code et de tests unitaires, mais aucun fichier n’a été essayé sur ce robot ; la manette UDP et la demande de position assise lors de sa perte ont été testées sur l’ordinateur de développement, pas sur le robot. L’installateur actualisé a été exécuté une fois sur la carte, mais la restauration sur une carte réelle reste à tester. LSM6DSV16X en I2C direct reste une voie testée sur bus simulé.

Sauts d'attitude BNO085 : un résultat limité de gyro-fusion à un seul robot

Dans le rapport de l’auteur du 15 octobre ↗, l’orientation fusionnée calculée par la puce BNO085 sautait parfois de 20–60° en un seul pas de 20 ms pendant la marche, alors que le gyroscope indiquait peu de rotation. Le fork peut intégrer les mesures du gyroscope et les comparer lentement à l’orientation de la puce. Par défaut, il publie toujours la valeur de la puce ; le mode alternatif gyro doit être sélectionné volontairement. Sur ce robot, la séquence antérieure chip totalisait 62 secondes debout en mode marche, neuf secondes cumulées de commande au joystick et trois chutes. Une séquence ultérieure gyro totalisait 634 secondes debout, 60 secondes cumulées de commande au joystick et une chute entre les sollicitations ; aucune chute n’a eu lieu pendant le maintien du joystick. La courte vidéo de marche enregistrée dans le commit ↗ montre les progrès de l’auteur, pas un essai de distance. Ces séquences étaient de durées différentes et non alternées, et les journaux et vidéos bruts complets restent privés : il ne s’agit ni d’un résultat A/B contrôlé ni d’une preuve de marche sur longue distance. La cause interne à la puce soupçonnée est une déduction de l’auteur à partir de sa télémétrie, pas une conclusion du fabricant.

Le même rapport mesurait ce canard à 806 g, révélait des virages faibles et enregistrait un autre redémarrage complet en mode marche. Il n'établit pas si ce redémarrage était une coupure de courant ou un blocage, ni une réparation prouvée. Le guide fork ↗ décrit les vérifications shadow-first et comment revenir en mode puce sur une version particulière ; copier ses seuils gyroscopiques, ses gains de servo, son orientation IMU ou son câblage vers un autre robot n'est pas une recette générale. La réinstallation du firmware d'origine kissqy supprime toujours la prise en charge I2C du fork. Pour les nouvelles constructions de cartes de bus, utilisez le guide FT6 RevA séparé ; ce n'est pas un firmware pour un module I2C prêt à l'emploi.

Images de montage et étapes encore manquantes

La série d'assemblages ↗ du créateur de CAO/BOM comprend sept vidéos numérotées de 1 à 6 et 8 ; son CAD README actuel ↗ ne répertorie toujours que les six premiers et ne modifie pas les anciennes exigences Feetech 3MF ou TPU. L'épisode 7 est absent. Utilisez la liste directe des chapitres dans notre guide des tutoriels DIY. La note d'achat corrigée de l'auteur de la réplique ↗ recommande 1 Go ou 2 Go sans eMMC Zero 3W plus 32 Go de microSD au lieu de l'ancienne préférence eMMC de 2 Go/16 Go ; le test intégré rapporté utilisait une carte sans eMMC de 2 Go, et non une configuration testée de 1 Go. Documentez la révision de votre carte et utilisez l'image appropriée plutôt que de copier une demande d'achat entre les révisions.

Pour une construction de marche reproductible, les contrôles restants sont les déplacements mesurés sur un sol marqué, l'adhérence sur les parties de pied en TPU spécifiées, les démarrages répétables, les marges thermiques et de puissance et la compatibilité publique du patch IMU/runtime. La relecture stationnaire à 14 articulations du 28 septembre et la configuration à 15 servos du 11 octobre restent des tests historiques plus restreints. Ce site n'a pas imprimé, flashé ou exploité le robot ; conserver un journal de fabrication avec la carte exacte, le micrologiciel, le modèle et les pannes.