Was wir ausgeliefert haben – und wohin R+D als Nächstes geht

Hallo ihr Lieben,

ich war in letzter Zeit ziemlich ruhig – aber nicht, weil nichts passiert wäre. Die meiste Zeit der vergangenen zwei Monate habe ich damit verbracht, einige der unspektakulärsten und zugleich wichtigsten Teile von R+D neu aufzubauen: Dokumentation, Browser-Tools, Firmware-Releases, die Wiederherstellung nach Updates und die Kommunikationsebene, die unsere Geräte gemeinsam nutzen.

Die Richtung wird zunehmend klarer. Ich möchte, dass unsere Produkte offen und hackbar bleiben und zugleich für Menschen, die sie einfach benutzen möchten, deutlich leichter und zuverlässiger werden. Diese Ziele stehen nicht im Widerspruch. Bessere gemeinsame Grundlagen ermöglichen es uns, beides zu unterstützen.

Hier erfährst du, was jetzt verfügbar ist, was noch getestet wird und warum ich das für wichtig halte.

Jetzt verfügbar

Dokumentation, die wir frei halten und verbessern können

Unsere Benutzerhandbücher, Entwicklerdokumentation und OHAI-Montageanleitungen laufen jetzt auf einem Fumadocs-Stack, den wir selbst kontrollieren.

Die alte Dokumentationsplattform war viel zu teuer geworden und erschwerte ganz normale Bearbeitungen unnötig. Das neue Setup ist schneller, bleibt kostenlos lesbar und speichert die eigentliche Quelle in Git, statt sie in einem proprietären Editor zu verstecken. Außerdem schafft es Raum für von Menschen verfasste Anleitungen, direkte Korrekturen aus der Community, interaktive Tools und ausführlicheres Montagematerial.

Die OHAI-Anleitungen haben ihr auf die Montage ausgerichtetes Layout zurück – einschließlich Fotos, Stücklisten, Bildunterschriften und interaktiven KiCad-Ansichten der Platinen. Das ist nicht nur eine visuelle Migration, sondern eine bessere Grundlage, um zu dokumentieren, wie die Maschinen tatsächlich gebaut, repariert und verändert werden.

Du kannst die Benutzerhandbücher, die Entwicklerdokumentation und die OSSM-Montageanleitung jetzt durchsehen.

Die OSSM-Browser-Tools sind zurück

Der OSSM-BLE-Controller ist wieder live und ermöglicht die direkte Steuerung über einen kompatiblen Desktop-Browser.

Auch der OSSM-Funscript-Player ist als experimentelles Tool zurück. Er kann ein lokales Video und Funscript gemeinsam über Web Bluetooth abspielen, ohne eine der beiden Dateien hochzuladen; sie bleiben in deinem Browser.

Browserbasierte Firmware-Tools sind für OSSM, DTT, Lockbox und RADR ebenfalls wieder live. Sie sind dafür gedacht, offizielle Firmware über einen Desktop-Browser zu installieren oder wiederherzustellen, wenn die entsprechende Anleitung oder der Support-Ablauf dich dazu auffordert.

Unauffällige Arbeit an der Zuverlässigkeit aller Geräte

Ein großer Teil der aktuellen Arbeit ist ganz bewusst langweilig. Die Firmware-Veröffentlichung für OSSM, RADR, DTT und Lockbox verfügt jetzt über strengere Validierung, unveränderliche Release-Artefakte, eine besser vorhersehbare Versionsvergabe und sichereres Wiederherstellungsverhalten. Dadurch sinkt die Wahrscheinlichkeit, dass einem Gerät der falsche Build angeboten wird oder es wiederholt versucht, dasselbe Update zu installieren.

Es gab auch kleinere, produktspezifische Korrekturen. OSSM erhielt Fehlerbehebungen für Drift und wiederholte Auslösungen des hinteren Endanschlags bei BLE-Sitzungen. DTT kann abgeschlossene Trainingsergebnisse jetzt bewahren, wenn ein Upload fehlschlägt, und verfügt über einen sichereren Migrationspfad für ältere Steuerplatinen. Bei Lockbox wurden die Displaystabilität und das Pausenverhalten verbessert. RADR hat eine zuverlässigere Release-Kette sowie öffentliche CAD-Daten für seine Batterieabdeckung.

Diese Änderungen sorgen nicht für spektakuläre Demo-Videos, machen aber alles, was darauf aufbaut, weniger anfällig.

rad-ble ist öffentlich

Ich habe rad-ble v1.0.0 als öffentliche, versionierte ESP32-Bibliothek und als öffentliches, versioniertes Protokoll veröffentlicht.

Das Ziel ist, unseren Geräten eine gemeinsame Sprache für Steuerungen, Telemetrie, Ressourcen, gestreamte Eingaben, Ausgaben und Firmware-Updates zu geben. Entwickler sollten nicht für jedes R+D-Produkt eine völlig andere Sammlung von Konventionen neu entdecken müssen.

Die Bibliothek selbst ist jetzt verfügbar. Ihre Firmware-Integrationen durchlaufen gerade das Staging für OSSM, RADR, DTT und Lockbox, daher möchte ich noch nicht behaupten, dass die gesamte Produktfamilie migriert ist.

Woran ich als Nächstes arbeite

Reibungsloseres und sichereres OSSM-Streaming

Das größte aktive Vorhaben ist ein umfangreiches OSSM-BLE-Streaming-Update.

Heute kann ein Strom eingehender Positionen ungleichmäßige Zeitabstände, plötzliche Sprünge, verspätete Pakete oder einen Rückstau enthalten, der nicht mehr relevant ist. Eine Maschine sollte diese Eingaben nicht blind reproduzieren.

Der neue Planer behandelt den Strom als zeitgesteuerte Trajektorie. Er begrenzt Ruck und Beschleunigung, verwirft veralteten Rückstau, verbessert Pufferung und Verbindungs-Timing und hält Ziele innerhalb abgesicherter Verfahrgrenzen. Wenn die Eingabe ausbleibt, kann er eine sanfte Rückkehr in den sicheren Bereich anwenden und anschließend beim Stoppen der Wiedergabe seinen Bewegungszustand sauber zurücksetzen. Der Branch enthält außerdem Belastungsmetriken und Tools zur Hardwarevalidierung, damit das Verhalten gemessen und nicht geraten werden muss.

Das Ganze befindet sich noch in der Prüfung und im Hardwaretest. Es ist das wichtigste Thema, bei dem ich technisch neugierige OSSM-Besitzer und Entwickler zum kritischen Testen einladen möchte.

Eine offene Steuerungsebene für die gesamte Produktfamilie

Der gleiche BLE-v1-Vertrag wird ebenfalls in RADR, DTT und Lockbox integriert. Das bedeutet nicht, jedes Produkt in eine identische Schnittstelle zu zwingen. Es bedeutet, gemeinsame Konventionen für Discovery, Identität, Telemetrie und Updates zu verwenden, während jedes Gerät die für es sinnvollen Fähigkeiten anbietet.

RADR ist hier besonders nützlich: Es ist sowohl ein Produkt als auch ein offener, konfigurierbarer Controller und profitiert daher direkt von klareren Ressourcen und umfangreicheren Live-Steuerungen.

Überprüfbare Firmware, ohne Menschen auszusperren

Ich füge außerdem eine signierte Herkunftsangabe für Firmware hinzu. Offizielle Builds werden kryptografische Nachweise darüber enthalten, woher sie stammen, und Tools werden diese Nachweise anzeigen können.

Das ist weder Secure Boot noch Flash-Verschlüsselung und auch kein Plan, Community-Firmware zu blockieren. Besitzer und Maker werden weiterhin ihren eigenen Code erstellen und flashen können. Bei der Herkunft geht es darum, den Ursprung sichtbar zu machen, nicht darum, aus offener Hardware ein gesperrtes Gerät zu machen.

Auf der Entwicklerseite räume ich außerdem die DTT-Schedule- und Session-APIs auf, füge Completion-Webhooks hinzu und behebe das Verhalten der Lockbox-API bei Zeitdauern, damit verdiente Anpassungen erhalten bleiben. Diese Änderungen werden noch geprüft.

Die übergeordnete Richtung

Die nützliche Bedeutung von „offen“ besteht nicht nur darin, Quellcode auf GitHub zu stellen. Es bedeutet, Menschen verständliche Protokolle, funktionierende Tools, reparierbare Hardware, korrigierbare Dokumentation und einen sicheren Weg zum Experimentieren zu geben.

Gleichzeitig darf Offenheit keine Entschuldigung für unzuverlässige Releases oder unsichere Bewegungen sein. Die normale Nutzung soll ruhiger und vorhersehbarer werden, während die Grenzen konfigurierbarer werden.

Das bedeutet mehr gemeinsame Open-Source-Grundlagen, mehr browserbasierte Tools, wo sie sinnvoll sind, bessere Tests in Stufen und eine Dokumentation, die als Teil des Produkts und nicht als Nebensache behandelt wird.

Wenn du helfen möchtest, probiere die OSSM-Tools aus, sieh dir rad-ble an oder prüfe die OSSM-Streaming-Arbeit. Fehler, ungewöhnliche Randfälle, Korrekturen an der Dokumentation und fundierter Widerspruch sind gleichermaßen hilfreich.

Danke, dass du weiterhin mit mir daran baust.

— AJ