MicroDuck 0.18.1 : démarrage, reprise et réglages

Le contrôle n’attend plus systématiquement 180 secondes

Pollen Robotics a publié 0.18.0 le 29 octobre à 12:57:56 UTC, puis 0.18.1 à 16:49:37 UTC. Cette dernière version stable est fixée à7d866d0f. Notre contrôle du 30 octobre est une autre date ; l’article 0.17.9 reste un repère historique.

Le minuteur démarre après une seconde et surveille updaterd, robotd, configd et btd. Un état failed ou au moins trois redémarrages transmet la décision à robot-rescue ; dix secondes continues en active pour les membres chargés terminent le contrôle. Délai par défaut 60 s, borné à 20–300 s. Une unité arrêtée ou non stabilisée sans preuve d’échec est laissée telle quelle ; les unités non chargées sont ignorées. La reprise a encore ses propres conditions : active en attente de matériel ne veut pas dire prêt à bouger.

• Publication stable 0.18.1
• Implémentation figée du contrôle de démarrage

Séparer mise à jour du démon et du système

L’interface os demande les partitions A/B de microduck_yocto et son script. Sinon la carte répond NOT_SUPPORTED/15. os status lit partitions, progression et last_result ; os check interroge le canal. apply et switch changent l’état puis redémarrent, refusent le mouvement ou une session distante active et partagent le verrou du démon. Une demande acceptée indique le début du travail : relire last_result après redémarrage.

La base provisionnée reste /etc/robot/robotd.toml ; /var/lib/robot/robotd.toml contient les choix du propriétaire, prioritaires clé par clé. L’éditeur écrit cette couche et reprend les anciennes modifications reconnues qui diffèrent des modèles distribués. Les clés inconnues sont conservées et signalées. Un choix volontaire identique à une ancienne valeur par défaut ne peut être distingué. Le jeton HF rejoint le stockage persistant avec lien de compatibilité ; ne le publiez pas. Cela ne donne pas d’A/B à une réplique Armbian personnelle.

• Référence officielle des commandes OS
• Code des couches de configuration

Les modèles communautaires demandent toujours un choix

0.18.0 soumet l’obtention de politiques non officielles à policy.allow_community. Publication du fichier, autorisation de téléchargement et compatibilité d’exécution sont trois contrôles distincts. Le jeu officiel vérifié reste v8 ; une mise à jour du démon ne rend pas officiel un modèle communautaire.

0.18.0 inclut aussi les changements de caméra, vidéo sur liaison faible et prédiction de chute indiqués dans la publication. Nous avons lu versions, manifests et code fixé, sans installer de démon, basculer de partition ou essayer un robot. Commencez par noter le build actif, la couche mise à jour et les journaux existants.

1. Noter le build du démon et vérifier la présence réelle de partitions A/B.
2. Comparer les réglages effectifs du propriétaire et conserver les journaux de mise à jour et de démarrage.
3. Après l’intervention du propriétaire, lire le résultat plutôt que conclure à partir d’une page déconnectée.

• Changements originaux de 0.18.0
• Autorisation communautaire dans le code