MicroDuck 0.18.1: Startprüfung, OS-Update und Einstellungen

Die Startprüfung wartet nicht mehr pauschal 180 Sekunden

Pollen Robotics veröffentlichte 0.18.0 am 29.Oktober um 12:57:56 UTC und 0.18.1 um 16:49:37 UTC. Letzteres ist die stabile Version am Commit7d866d0f. Der 30.Oktober bezeichnet unsere Quellenprüfung; die 0.17.9-Seite bleibt eine historische Beschreibung.

Der Timer beginnt eine Sekunde nach dem Booten und beobachtet updaterd, robotd, configd und btd. failed oder mindestens drei Neustarts seit diesem Boot übergeben an robot-rescue. Sind die geladenen Mitglieder zehn Sekunden durchgehend active, endet die Prüfung. Standardfrist 60 s, begrenzt auf 20–300 s. Gestoppte oder noch nicht stabile Dienste ohne Fehlernachweis bleiben unberührt; nicht geladene Units werden übersprungen. Rescue prüft eigene Voraussetzungen. Ein auf Hardware wartender aktiver Dienst belegt keine Bewegungsbereitschaft.

• Stabile Veröffentlichung 0.18.1
• Fixierte Implementierung der Startprüfung

Zuerst die Ebene des Updates bestimmen

Daemon und gesamtes Betriebssystem werden getrennt aktualisiert. os setzt das A/B-Layout von microduck_yocto und dessen Updateskript voraus; ohne Unterstützung folgt NOT_SUPPORTED/15. os status liest Slots, Fortschritt und last_result, os check fragt den Kanal ab. apply und switch ändern Zustand und starten neu, verweigern Bewegung oder aktive Fernsitzungen und teilen die Sperre mit Daemon-Updates. Eine angenommene Anfrage startet nur den Vorgang; nach dem Neustart last_result lesen.

Die bereitgestellte Basis liegt unter /etc/robot/robotd.toml, Besitzerwerte in /var/lib/robot/robotd.toml haben je Schlüssel Vorrang. Der Editor schreibt diese Ebene und übernimmt erkannte alte Abweichungen von ausgelieferten Vorlagen. Unbekannte Schlüssel bleiben erhalten und werden benannt. Eine bewusst gewählte Einstellung genau auf einem ausgelieferten Standard lässt sich nicht erkennen. Das HF-Token wechselt in persistenten Speicher mit Kompatibilitätslink. Nicht veröffentlichen und daraus keine A/B-Unterstützung eines privaten Armbian-Nachbaus ableiten.

• Offizielle OS-Befehlsreferenz
• Implementierung der Konfigurationsschichten

Community-Policies brauchen weiterhin eine eigene Freigabe

Ab 0.18.0 setzt der Abruf inoffizieller Policies die bewusste Wahl policy.allow_community voraus. Verfügbare Datei, Downloadfreigabe und Laufzeitkompatibilität sind getrennte Fragen. Der überprüfte offizielle Policy-Satz bleibt v8; ein Daemon-Update macht ein Community-Modell nicht offiziell.

0.18.0 enthält zudem Kamera-, Schwachnetzvideo- und Sturzvorhersageänderungen laut Originalveröffentlichung. Hier wurden Releases, Manifeste und fixierter Code gelesen, ohne Daemoninstallation, Slotwechsel oder Robotertest. Ausgangspunkt sind tatsächlicher Build, Updateebene und vorhandene Protokolle.

1. Aktiven Daemon-Build und tatsächlich vorhandene A/B-Slots festhalten.
2. Wirksame Besitzerwerte vergleichen und vorhandene Update-/Bootprotokolle sichern.
3. Nach einem vom Besitzer ausgeführten Update das Ergebnis lesen, statt einen Seitenabbruch als Erfolg zu werten.

• Originaländerungen von 0.18.0
• Community-Abrufrecht im Code