VENOM Engineering-Log

18 Gelenke, beschädigte Getriebe, zerstörte Leistungselektronik und jede Menge Fehlersuche: Warum VENOM gerade auf dem Operationstisch liegt – und weshalb diese Rückschläge ein wichtiger Teil seiner Weiterentwicklung sind.

Ganzen Beitrag lesen →

Ziel: Herausfinden, warum der rechte hintere Oberschenkel beim Aufrichten zurückbleibt, während die anderen fünf Beine den Körper anheben.

Ausgangslage: Der betroffene Servo meldet beim Aufrichten eine sehr hohe Last und bleibt rund 16° hinter seiner Sollposition. Der Servo-Controller schickt ihm dabei praktisch denselben Puls wie dem gleichen Gelenk am rechten Vorderbein, das sauber folgt.

Vorgehen:

1. Rückmeldung prüfen: Bein von Hand bewegt – der digitale Zwilling folgt. Die Winkelrückmeldung dieses Gelenks ist in Ordnung; die scheinbar „eingefrorene“ Stellung war die echte Lage des Beins.
2. Firmware gegenprüfen: Eine ältere Firmware-Version zeigt dasselbe Verhalten.
3. Mit dem Original vergleichen: Die Original-Firmware schaltet beim Start die automatische Kraftabschaltung der Oberschenkel im Servo-Controller ab, unsere Firmware tat das nicht. Hypothese: Die Kraftabschaltung hält das am stärksten belastete Bein fest. Wir haben eine Version mit genau diesem Startschritt gebaut, geflasht und am Roboter getestet.

Ergebnis: Auch mit abgeschalteter Kraftabschaltung kommt das Bein nicht hoch. Die Hypothese ist widerlegt. Wir sind deshalb auf den vorherigen Stand zurückgegangen, bei dem die Kraftabschaltung aktiv bleibt – die Lastüberwachung soll ausdrücklich an sein. Die Rohwerte der Lastmessung kamen in beiden Versionen weiter auf allen 18 Kanälen an.

Erkenntnis: Sensorik, Firmware und Sollwerte scheiden praktisch aus. Übrig bleiben die Antriebsseite (Servo, Getriebe, Versorgung, Stecker, Kabel) und der Ausgang des Servo-Controllers.

Nächster Schritt: Steckertausch mit dem Oberschenkel vorne rechts. Wandert der Fehler mit dem Stecker, liegt es an Servo oder Kabel; bleibt er hinten, am Ausgang des Controllers.

Ausgangslage: Der vollständige Lauf aller 20 End-to-End-Szenarien im Zwilling ergab 17 bestandene. Rot waren das autonome Treppenziel, die Navigation zwischen Gegenständen (5 von 6 Zielen) und das Gehen auf vier Beinen (kein Vortrieb). Auf dem unveränderten Ausgangsstand sind dieselben drei rot – es waren also bestehende Schwächen, keine neuen Fehler.

Was wir gefunden und geändert haben (Entwicklungszweig, noch nicht in den Hauptstand übernommen):

• Vierbeiner: Im Vierbeinstand standen die angehobenen Vorderbeine in den Messkegeln der ToF-Sensoren. Mit geänderter Haltung ist der Test grün.
• Treppe: Überkopf-Hindernisse zählen nur noch aus ausreichend genauen Kartentreffern – das allein macht den Zieltest grün. Zusätzlich dreht sich der Rumpf beim Kaltstart, wenn der erste Kurs schräg liegt und der Boden davor noch unbeobachtet ist, und die Aufsetzsuche meidet Punkte, die die vorderen ToF-Sensoren verdecken.
• Navigation: Jetzt 6 von 6 Zielen, aber zwei Berührungen eines 20 mm hohen Stabs. Ursachen: Die 50-mm-Kartenzelle mittelt Boden, Stabkante und Oberseite auf 5–13 mm – unter die 15-mm-Schwelle für „erhöht“. Und eine Rampenausnahme verbindet einen so niedrigen Stab mit dem Boden.

Weitere echte Ursachen, die dabei sichtbar wurden: Eine Fußplatzierung führt zu einer Eigenkollision („Knie im Rumpf“), und die Lageschätzung speichert eine schräg gesehene Wand mit 94,8° statt 90° und korrigiert danach in die falsche Richtung. Beides wird gerade repariert.

Regel dabei: Keine Schwelle und keine Prüfbedingung wird gelockert, damit ein Test grün wird. Eine Änderung wird erst übernommen, wenn kein bisher grüner Test rot wird.

Ziel: Prüfen, ob eine gelernte Korrektur (Residual) auf dem bestehenden Gang die Belastung der Servos senkt, ohne harte Sicherheitsgrenzen zu verletzen.

Aufbau (nur Simulation): MuJoCo-Zwilling aus unserem rekonstruierten CAD-Modell. Die Policy darf nur Schritthöhe, Schrittdauer und später Tempo (0,4–1,0) und Körperhöhe (±15 mm) innerhalb der Grenzen des bestehenden Gangs verändern. Harte Grenzen: Gelenkmoment unter 1,0 Nm, Neigung unter 5°, Servosättigung unter 0,05 s. Die Bodenreibung wird im Training variiert.

Ergebnis auf ebenem Boden (Reibung 0,6 und 1,4, im Training nicht gesehen, je zwei Seeds):

• Vorwärts: Spitzen-Gelenkmoment −4,8 % und −3,6 %
• Drehen: −2,7 % und −2,6 %
• Seitwärts: −1,5 % und +1,8 % – also einmal schlechter

Gelernt wurde vor allem eine um 10–12 % längere Schrittdauer.

Ergebnis im Gelände: Auf unebenem Gelände überschreitet schon der bestehende Gang die 1-Nm-Grenze (1,31–1,49 Nm), die Policy bleibt mit 1,05–1,41 Nm ebenfalls darüber. Weder CEM noch PPO findet eine zulässige Lösung. Die Grenze haben wir nicht gelockert.

Neuer Befund (01.11.): Über den vollständigen Laufzeitpfad mit eigener Umgebungskarte hält die Rampe alle Grenzen (0,86 Nm, 1,3°). Der frühere negative Rampenbefund kam vom vereinfachten Testaufbau. Das unebene Gelände bleibt mit 1,40 Nm über der Grenze.

Erkenntnis: Schrittzeit und Schritthöhe sind nicht der Hebel. Nötig sind ein kraftbasierter Lastausgleich im Stand und eine bessere Nahfeldwahrnehmung vor dem ersten Schritt. Daran arbeiten wir als eigenes Thema. Nichts davon läuft bisher auf der Hardware.

Ziel: Die originale PS2-Funkfernbedienung soll auf unserer neuen Board-Firmware genauso funktionieren wie mit der Original-Firmware. Gleichzeitig soll der Raspberry Pi 5 laufend Gelenkwinkel und Lastwerte vom Servo-Board lesen.

Ausgangslage: Mit der neuen Firmware war kein einziges Funkpaket gültig, und sobald die Funke aktiv war, gingen Anfragen des Pi verloren.

Gefundene Ursachen (Auswahl):

• Compiler statt Code: Der neuere Compiler (avr-gcc 7.3) setzt eine Verzögerungsschleife der Software-Seriellschnittstelle nicht mehr direkt ein. Dadurch tastete der Empfang jedes Bit zu spät ab, jede Prüfsumme schlug fehl. Die Zeittabelle haben wir über eine Taktzählung im erzeugten Maschinencode neu bestimmt.
• Servo-Controller nur beim Start gesucht: Antwortete er in diesem Moment nicht, blieb er bis zum nächsten Reset unsichtbar. Jetzt sucht die Firmware alle 500 ms nach.
• „S-Bewegung“ beim Aufrichten: Die Hüften schwangen vor und zurück, weil vor jedem Aufstehen die komplette Kinematik-Konfiguration neu in den Servo-Controller geschrieben wurde. Das Original nutzt die dort gespeicherten Werte. Ohne diese Schreibfolge steht VENOM wieder „sauber wie früher“ auf.
• Verlorene Pi-Anfragen: Der Funk-Interrupt hat Vorrang vor dem UART-Interrupt. Während eines 24-Byte-Funkpakets lief der nur zwei Byte große Empfangspuffer über, 4–5 % der Anfragen gingen verloren. Jetzt holt der Funk-Interrupt die wartenden UART-Bytes am Ende jedes Funkbytes selbst ab: 0 Verluste und 6,2 statt 4,2 Abfragen pro Sekunde.

Ergebnis am Roboter: START schaltet die Servos ein und fährt die Grundstellung an, Aufrichten und Fahren per Funke funktionieren, die Signaltöne entsprechen dem Original. Das Kalibriermenü ist erreichbar; eine echte Kalibrierung haben wir noch nicht ausgeführt.

Erkenntnis: Gleicher Quellcode heißt nicht gleiches Timing. Bei zeitkritischen Protokollen auf 8-Bit-Controllern entscheidet der erzeugte Maschinencode – den muss man lesen, nicht nur den C++-Quelltext.

Ausgangslage: Ein Firmware-Update für das Servo-Board (ATmega328P) mit 31.856 Byte wurde geschrieben, und das Flash-Werkzeug meldete die Daten als verifiziert. Danach antwortete das Board nicht mehr über USB, die Rückmeldung der Beine fiel aus.

Ursache: Mit der eingestellten Fuse-Konfiguration beginnt der Bootloader bei 30.720 Byte (Adresse 0x7800). Das Programm war größer und ragte in diesen Bereich.

Lösung: Das Board sitzt ganz unten im Roboter, der Zugang bedeutet eine Teildemontage. Über einen ISP-Programmer (direkter Programmieranschluss) haben wir es gerettet und dabei die Fuse-Werte ausgelesen.

Was sich im Ablauf geändert hat:

• Jeder Build prüft die Grenze von 30.720 Byte und hält eine Reserve ein.
• Geflasht wird nur der Anwendungsbereich, als vollständiges, aufgefülltes Abbild.
• Vor und nach jedem Flash lesen wir den kompletten Speicher zurück und vergleichen die Prüfsumme mit dem erwarteten Stand.

Erkenntnis: „Verifiziert“ heißt beim Flashen nur, dass die geschriebenen Bytes stimmen – nicht, dass das Programm in den verfügbaren Platz passt.

Ausgangslage: Die WLAN-Verbindung des Roboters über einen USB-Stick brach immer wieder ab.

Ursache: Erkennt der Raspberry Pi 5 keine 5-A-Versorgung (hier meldete die Firmware 3 A und keine USB-PD-Daten), begrenzt er den Strom für alle USB-Geräte zusammen auf 600 mA. Angemeldet waren 760 mA: WLAN-Stick 450 mA, rundes Display 120 mA und zwei USB-Seriell-Wandler mit 100 und 90 mA.

Lösung: usb_max_current_enable=1 in der Boot-Konfiguration hebt die Grenze auf 1,6 A. Nach dem Neustart war die Einstellung aktiv, eine Überstrommeldung gab es nicht, und der Stick startet zuverlässig.

Was offen bleibt: Die Funkqualität auf dem genutzten WLAN-Kanal ist weiterhin mäßig (rund 8 % Paketverlust). Das ist ein eigenes Thema.

Hinweis für Nachbauer: Diese Einstellung nur setzen, wenn die Versorgung den höheren Strom tatsächlich liefern kann.

Was passiert ist: Wochenlang lebte VENOM vor allem im digitalen Zwilling. Jetzt meldet die echte Mechanik Gelenkstellungen, Servo-Last und Bewegung zurück. Bewegt man ein Bein am Tisch, bewegt es sich auch im Zwilling auf dem Monitor.

Warum das wichtig ist: Ein Zwilling ist nur so gut wie seine Übereinstimmung mit der echten Maschine. Mit der Rückmeldung können wir Modell und Körper Gelenk für Gelenk abgleichen.

Einordnung: Der Roboter stand dabei abgestützt auf dem Tisch. Gehversuche mit dem Zusammenspiel aus Zwilling und Hardware stehen noch aus.

Video und Beitrag zu diesem Moment

Ziel: VENOM soll Sprachbefehle wie „Stopp“ über seine eigenen zwei Mikrofone (MAX4466 am ESP32) erkennen.

Messung am Roboter: Fünf Paare aus Ruhe und abgespielter Sprachausgabe.

• Im Summensignal der beiden Mikrofone ist die Sprache von der normalen Schwankung in Ruhe (±1,1 dB) nicht zu unterscheiden. Der Störabstand liegt dort bei höchstens −5 dB.
• Im Differenzsignal (links minus rechts) ist sie messbar, aber nur mit +2,0 bis +3,4 dB. Das Rauschen ist zu 98 % auf beiden Kanälen gleich (Gleichtakt) – ein Hinweis auf Versorgung oder Masse statt Luftschall.
• WLAN an oder aus macht keinen Unterschied.

Gegenprobe in der Simulation: Auf diese Messwerte kalibriert, erkennt keine Software-Variante die Befehle. Nötig sind 15 bis 20 dB mehr Signal an der Quelle. Eine frühere eigene Schätzung von „+8 bis +10 dB“ war falsch und ist korrigiert.

Erkenntnis: Zuerst messen, dann filtern. Ein Filter kann kein Signal herzaubern, das im Rauschen verschwunden ist.

Nächster Schritt: Hardware-Diagnose in drei Schritten: Mikrofonkapseln abdecken (Luftschall oder elektrische Einkopplung?), Verstärker testweise aus Batterien versorgen, ADC-Eingang auf eine feste Referenzspannung legen.