AKWORKZ · VENOM · BUILD IN PUBLIC
VENOM: ein Hexapod, öffentlich entwickelt
Entwicklungsstand auf einen Blick
Jede Aussage über VENOM gehört in genau eine dieser sechs Gruppen. Was nur simuliert ist, steht nicht bei „real getestet“.
Real getestet
- Funkfernbedienung auf eigener Board-Firmware: START schaltet die Servos ein und fährt die Grundstellung an, Aufrichten und Fahren per Funke, Signaltöne wie im Original.
- Gelenkrückmeldung: Ein von Hand bewegtes Bein erscheint im digitalen Zwilling.
- Datenverbindung Pi 5 ↔ Servo-Board bei aktiver Funke ohne verlorene Anfragen.
- Raspberry Pi 5 mit Steuerungssoftware, Kameras und rundem Display-Auge im Betrieb.
- Rohwerte der Servo-Last auf allen 18 Kanälen.
In Software umgesetzt
- Neuer Gang über die Roboterlogik für Studio, Bluetooth-Controller und Sprachbefehle – am Roboter noch nicht gefahren.
- Kalibrierung per Funke wie im Original: Menü erreichbar, echte Kalibrierung noch nicht ausgeführt.
- Gelenk-Werkzeug im Studio zum Bewegen einzelner Gelenke.
- Energieanalyse und Antriebsidentifikation – bisher nur mit Simulations- bzw. synthetischen Daten.
Nur Simulation
- Digitaler Zwilling in MuJoCo mit dem Original-Gang und einer zweiten Gangsteuerung.
- 17 von 20 End-to-End-Szenarien bestanden; Korrekturen für Vierbeinergang und Treppe auf einem Entwicklungszweig.
- Einzelne Prüffälle: Engstelle, Absenken, Personenabstand, Selbstaufrichtung.
- Gelernte Gangkorrektur: 4–5 % weniger Gelenkbelastung auf ebenem Boden.
In Entwicklung
- Fehlersuche am rechten hinteren Oberschenkelservo.
- Montagebezug der IMU (Kalibrierposen); bis dahin laufen Sicherheitsfunktionen mit Ersatzannahmen.
- Messreihen und Kalibrierung der ToF-Sensoren.
- Navigation zwischen Gegenständen ohne Berührung (Simulation).
- Lastausgleich im Stand für unebenes Gelände.
Geplant
- Erste echte Gehprobe mit dem neuen Gang.
- Kalibrierung der Beine per Funke am Roboter.
- Stromsensoren für eine echte Energiemessung.
- Freigabe längerer autonomer Patrouillen erst nach bestandenem Gesamttest.
Gescheitert / verworfen
- Kraftabschaltung als Ursache für das hängende Hinterbein – widerlegt.
- Firmware-Update ragte in den Bootloader; Board nur per ISP zu retten.
- Spracherkennung über die eigenen Mikrofone – Störabstand zu gering.
- Gelernte Policy im unebenen Gelände – keine Lösung unter 1 Nm.
- Vollständige autonome Patrouille in der Simulation – noch nicht bestanden.
Systemaufbau
Der Raspberry Pi 5 übernimmt Wahrnehmung und Planung. Die zeitkritische Servoansteuerung bleibt auf den bewährten Controllern des Originals: dem DaVinci-Board mit unserer eigenen Firmware und dem Orion-Servo-Shield.
Bewegung
- 18 × HV220-Servos, drei je Bein. Im Zwilling mit Positionsregelung bis 1,55 Nm modelliert; Steifigkeit, Reibung und Trägheiten sind dort noch Annahmen.
- Orion Servo-Shield (Renesas H8): regelt die Servos und liefert Winkel und Last je Kanal.
- DaVinci (ATmega328P): Gang und Kinematik wie im Original, Funkempfang, Brücke zum Pi. Programmspeicher bis 30.720 Byte, danach beginnt der Bootloader.
Wahrnehmung und Rechner
- Raspberry Pi 5 (8 GB) mit der Steuerungssoftware an Bord.
- Zwei Weitwinkelkameras für ein Stereo-Tiefenbild (noch nicht metrisch kalibriert).
- Vier ToF-Abstandssensoren an einem I²C-Multiplexer, IMU BNO085 per SPI.
- ESP32-WROOM mit zwei Mikrofonen, rundes 2,8-Zoll-Display als Auge.
Neueste Einträge im Engineering-Log
Datum, Ziel, Vorgehen, Ergebnis und Erkenntnis – auch wenn etwas nicht funktioniert hat.
9. November 2026VENOM: Wenn Servos ausfallen und Elektronik explodiert – Ein Blick in unsere RoboterwerkstattIn Entwicklung18 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.1. November 2026Hinterbein kommt nicht hoch: Hypothese IK-Kraftstopp widerlegtReal getestetGescheitert / verworfenIn EntwicklungRückmeldung, Ausgangssignal und Firmware geprüft, eine Original-Startfunktion nachgerüstet – das rechte Hinterbein bleibt trotzdem zurück. Die Ursache liegt auf der Antriebsseite.1. November 2026Simulation: 17 von 20 End-to-End-Szenarien – und was hinter den drei roten stecktNur SimulationIn EntwicklungVierbeinergang und Treppe sind auf einem Entwicklungszweig repariert. Die Navigation zwischen Gegenständen erreicht alle Ziele, berührt aber noch zweimal einen niedrigen Stab.1. November 2026Robot Learning im digitalen Zwilling: kleine Gewinne, ehrliche GrenzenNur SimulationGescheitert / verworfenEine gelernte Korrektur auf den bestehenden Gang senkt im Geradeauslauf die Gelenkbelastung um 4–5 %. Im unebenen Gelände findet weder CEM noch PPO eine zulässige Lösung.
Filme und Beiträge
Bisher veröffentlicht. Jede Karte sagt, was zu sehen ist: echte Aufnahme, Simulation oder CAD.
RealaufnahmeDigital trifft real: Der Zwilling folgt den Beinen
Real und Simulation, gekennzeichnetEin alter Roboter lernt, seine Umwelt zu verstehen
Simulation und StudioVENOM Studio: Engineering Deep-Dive
SimulationDer Weg wird enger: Haltung anpassen
Real, CAD und KonzeptWahrnehmung. Intelligenz. Bewegung.
RealaufnahmeDie echte Plattform in Bewegung
CADVom Bauteil zum System in Autodesk Inventor
RealfotoLive-Auge, Körpermodell und digitaler Zwilling
CADInnenraumplanung zwischen Elektronik, Mechanik und Service
Nächste Schritte
Am Roboter
- Ursache am rechten Hinterbein klären (Steckertausch).
- Kalibrierung der Beine per Funke.
- Montagebezug der IMU bestimmen.
- Erste Gehprobe mit dem neuen Gang.
- ToF-Messreihen, Mikrofon-Hardware.
In Software und Simulation
- Navigation zwischen Gegenständen ohne Berührung.
- Eigenkollision bei der Fußplatzierung beheben.
- Lastausgleich im Stand für unebenes Gelände.
- Stereo-Tiefe metrisch kalibrieren.
In der Dokumentation
- Vertiefende Artikel zu Elektronik und Versorgung – nach der physischen Abnahme.
- Zwilling gegen Hardware: Messreihen veröffentlichen, sobald sie vorliegen.
- Englische Fassung.
So dokumentieren wir
- Real ist real, Simulation ist Simulation. Jeder Eintrag trägt seinen Prüfstatus. Ein Video aus dem Zwilling wird nie als Hardwaretest ausgegeben.
- Fehlschläge gehören dazu. Widerlegte Hypothesen und verworfene Ansätze stehen mit Ursache im Log.
- Keine Grenze wird gelockert, damit ein Test besteht. Sicherheitsgrenzen wie 1 Nm Gelenkmoment oder 5° Neigung bleiben, auch wenn das Ergebnis dann „nicht bestanden“ heißt.
- Gemessene und geschätzte Größen bleiben getrennt. Fußkräfte schätzen wir aus Servo-Last und Bewegung; eigene Kraftsensoren in den Füßen hat VENOM nicht.
- Keine Zugangsdaten, Adressen oder internen Zugänge. Das vollständige technische Protokoll bleibt intern; hier steht, was für andere Entwickler nützlich und sicher ist.