Tian Yanlin, berichtet von Ao Feisi
QbitAI | Öffentlicher WeChat-Account QbitAI
Ziemlich heftig! Ein Hersteller humanoider Roboter will diesmal die technische Black Box bis ganz unten aufschlüsseln.
Man muss wissen: Open Source bei humanoiden Robotern ist gar nicht so einfach. Von der mechanischen Konstruktion und den elektrischen Systemen bis zur Gelenksteuerung und Bewegungsalgorithmik sind Hardware und Software eng miteinander verzahnt.
Manche Roboter wurden bisher zwar als „Open Source“ bezeichnet, aber was Entwickler erhielten, war oft nur ein SDK, ein paar APIs oder Teile des Algorithmus-Codes.
Die Gelenksteuerung ändern? Unmöglich. Die mechanische Konstruktion anpassen? Keine Baupläne verfügbar. Ein selbst trainiertes Modell auf dem echten Roboter laufen lassen? Die zugrunde liegende Schnittstelle ist die Hürde.
Doch jetzt dringt die Open-Source-Bewegung bei humanoiden Robotern bis in die tiefste Hardware-Schicht vor.
Den ersten Schritt machtRoboParty (萝博派对). Kürzlich hat RoboParty offiziell denFull-Stack-Open-Source-humanoiden Roboter RP1。
vorgestellt – von mechanischen Bauplänen, elektrischen Systemen und selbst entwickelten Gelenken bis hin zur unteren Steuerungsebene, Simulation, Training und Deployment. RoboParty will Entwicklern die gesamte Entwicklungskette des humanoiden Roboters offenlegen, von der Hardware bis zur Software.
Das ist auch der größte Unterschied zwischen einem Full-Stack-Open-Source-Ansatz und der bloßen Freigabe eines SDKs oder von Teilen des Algorithmus-Codes.
Entwickler können nicht nur die vorhandenen Funktionen des Roboters nutzen, sondern bis auf die unterste Ebene vordringen, erforschen, warum und wie er sich bewegt, und ihn sogar selbst verändern.
Auch die Bewegungsfähigkeiten des RP1 selbst können sich sehen lassen.
Mit einer Körpergröße von 135cm und verschiedenen Grundkonfigurationen mit 24 bis 30 Freiheitsgradenkann er die Anforderungen unterschiedlicher Szenarien wie Bildung und Forschung, Datenerfassung, Führung und Unterhaltung erfüllen. Der RP1 hat bereits eine Reihe von Bewegungsfähigkeiten auf dem echten Gerät demonstriert, darunter kontinuierliches Gehen, Nachahmung menschlicher Bewegungen, Störungskompensation und Wiederaufstehen nach einem Sturz.
Was diese Bewegungen ermöglicht, sinddie von RoboParty selbst entwickelten ROMOMO-Gelenkmodulesowie die zugehörigen Werkzeuge für Bewegungssteuerung und Training.
Auf der einen Seite die sichtbare Leistung des echten Roboters, auf der anderen Seite die unterste Technologiemebene, die den Entwicklern übergeben werden soll.
Für Entwickler gibt es jetzt mehr Möglichkeiten, aber vom offenen Code bis zur tatsächlichen Nutzung gibt es noch einiges zu beachten.
Warum sollte man bei humanoiden Robotern die unterste Ebene vollständig öffnen?
Auch wenn beides Open Source heißt: Wie weit ein humanoider Roboter tatsächlich geöffnet wird, kann einen enormen Unterschied machen.
Ein Beispiel: Ein Forschungsteam möchte, dass ein Roboter einen neuen Gang ausgibt.
Wenn der Hersteller nur die höheren APIs öffnet, können Forscher Gehbefehle erteilen und einzelne Parameter anpassen.
Sobald es jedoch um Motorreaktionen, die untere Steuerungsebene oder sogar die Gelenkkonstruktion geht, muss man den Hersteller um Hilfe bitten.
Fällt das Experimentsergebnis unbefriedigend aus, lässt sich außerdem nicht schnell eingrenzen, wo das Problem liegt.
Ist der Algorithmus schlecht trainiert? Kommen die Gelenke nicht nach? Oder gibt es Abweichungen zwischen dem Simulationsmodell und dem echten Roboter? Schicht um Schicht stehen technische Black Boxes im Weg, sodass Forscher kaum bis zum Grund vordringen können.
Wie ernst es einem Roboter-„Open Source“-Projekt ist, zeigt sich daran, bis zu welcher Ebene Entwickler Änderungen vornehmen können.
Wird nur das SDK offengelegt, bestehen die Aufgaben der Entwickler hauptsächlich darin, Funktionen aufzurufen. Werden die Steuerungsalgorithmen offengelegt, kann man darüber hinaus die Logik der Bewegungsgenerierung und -ausführung des Roboters erforschen.
Werden mechanische Zeichnungen, elektrische Systeme, Gelenkdaten, eingebettete Software sowie Simulations- und Trainingswerkzeuge offengelegt, erweitert sich der Forschungsspielraum erheblich.
Genau deshalb betont RP1 das „Full-Stack-Open-Source“-Prinzip.
Gerade für Forschungseinrichtungen ist die Autonomie in der Forschung enorm wichtig.
Dass der Roboter in der wissenschaftlichen Arbeit stabil läuft, auf einem anderen Gerät aber sofort umkippt – das ist in Laboratorien keineswegs selten. (doge)
Die Gelenkanordnung, die Geräteprotokolle, die Steuerfrequenz und sogar die Definition des Nullpunkts (d. h. welche Position eines Gelenks als 0°-Referenz dient) können die experimentellen Ergebnisse beeinflussen.
Wenn die zugrunde liegenden Materialien nicht zugänglich sind, müssen Forschende viel Zeit auf die Anpassung der Plattform verwenden. Manche Forschungsthemen werden sogar durch die Hardware eingeschränkt.
Ähnliche Sorgen haben auch Unternehmen für embodied KI-Modelle.
Nun kommen VLA, Weltmodelle und Bewegungssteuerungsstrategien nacheinander zum Einsatz: Die Modelle trainieren in der Simulation gut, doch an der realen Maschine gehorchen sie nicht unbedingt.
Beispielsweise plant das Modell, dass der Roboter ein Bein hebt, um ein Hindernis zu überqueren – in der Simulation klappt das reibungslos, an der realen Maschine scheitert es jedoch wegen abweichender Gelenkreaktionen oder Dynamik.
Liegt es am Modell oder hat der Roboter bei der Ausführung eine Abweichung gemacht?Wenn Daten, Steuerung und Hardware-Feedback alle eingesehen und angepasst werden können, gibt es mehr Anhaltspunkte, um das Problem einzugrenzen.
Auch die Hochschulbildung benötigt einen solchen Grad an Offenheit.
Früher mussten Studierende möglicherweise nur eine API aufrufen, um den Roboter vordefinierte Bewegungen ausführen zu lassen.
Wer aber wirklich verstehen will, wie ein Roboter funktioniert, reicht das reine Aufrufen von Schnittstellen offensichtlich nicht aus.
Wenn man Steuerungsalgorithmen selbst ändern, Komponenten austauschen oder sogar die mechanische Struktur neu entwerfen kann, ergeben sich naturgemäß größere Spielräume für Lehre und Forschung.
Forschungseinrichtungen wollen Autonomie, Unternehmen für embodied KI-Modelle wollen Effizienz in der Entwicklung, und Hochschulen wollen, dass Studierende wirklich praktisch arbeiten.
Die Ausgangspunkte dieser drei Kundengruppen scheinen unterschiedlich zu sein, doch tatsächlichwünschen sich alle, dass der Roboter den Forschungsanforderungen folgt und die Forschung nicht an den Funktionsgrenzen der Hersteller hängen bleibt.
Genau eine solche offene Forschungs- und Entwicklungsplattform soll RP1 laut RoboParty sein.
Natürlich hängt davon, wie tief die Open Source gehen kann, davon ab, was sie tatsächlich vorweisen kann.
Vom Gelenk bis zum Algorithmus – wie viel offenbart RP1 wirklich?
Im offiziellen Vorstellungsvideo kann der Roboter nicht nur laufen und springen, sondern mit visueller Unterstützung auch Parkour betreiben und Hindernisse überwinden, selbstständig Treppen auf- und absteigen, seinen Gang anhand des tatsächlichen Geländes selbstständig planen, nach einem Sturz schnell aufstehen, menschliche Bewegungen nachahmen, und nach Störungen sofort die Haltung anpassen, um das Gleichgewicht zu halten und den aktuellen Bewegungszustand beizubehalten.
Hinter diesen flüssigen Bewegungen steht das Zusammenspiel einer ganzen Reihe von Hard- und Software.
Beim Beispiel der Störungskompensation muss das Steuerungssystem die Bewegungen entsprechend dem Körperzustand anpassen, die Gelenkmodule sind für die Ausführung der Befehle verantwortlich, und die mechanischen Strukturen von Hüfte, Knie und Knöchel bestimmen, in welcher Haltung der Roboter die Anpassung abschließen kann.
Das Aufstehen nach einem Sturz ist noch komplexer: Wie der Körper den Boden berührt, wie die Gelenke Kraft aufbringen und wie sich der Schwerpunkt verlagert, muss alles aufeinander abgestimmt sein.
RP1 bietet zwei Konfigurationen des Roboterkörpers an.
Die Open-Source-Version verfügt über 24 aktive Freiheitsgrade, die Open-Source-Version Pro über 30, davon 2 Freiheitsgrade im Kopf und je 7 Freiheitsgrade in den beiden Armen, was sie besser für die Forschung an komplexen Manipulationen eignet.
Erwähnenswert ist außerdem, dass die Kopf- und Handmodule von RP1 wählbar sind, um sie an verschiedene Szenarien anzupassen.
Auf der Hardware-Ebene sind die Gelenkmodule ein zentraler Bestandteil.
RP1 ist mitdem von RoboParty selbst entwickelten integrierten Rotationsgelenk ROMOMO ausgestattet.
Laut der offiziell veröffentlichten Parametertabelle der Gelenke liegt der Nennwert derSpitzenmomente zwischen 25 und 160 N·mund die Module werden mit 48 V versorgt und nutzen CAN-FD-Kommunikation.
Huang Yi, Gründer von RoboParty, und die hinter ihm stehende RP1-Bauteilwand
Warum ist der Drehmomentabdeckungsbereich so breit?
Hüfte und Knie müssen den Körper tragen, was höhere Anforderungen an das Drehmoment stellt; die Enden der Arme müssen dagegen Gewicht, Volumen und Reaktionsgeschwindigkeit in Einklang bringen.
ROMOMO verwendetein Schema aus Innenläufer-Motor in Kombination mit einem NGW-Planetengetriebe. Die niedrigere Rotorträgheit begünstigt eine schnelle Reaktion, während das Planetengetriebe Steifigkeit, Überlastungsfähigkeit und Kosten zugleich berücksichtigt.
Auch die mechanische Struktur ist sorgfältig durchdacht.
Der RP1 verwendet eine nicht konkurrente Hüftkonstruktion und ein paralleles Knöcheldesign. Dabei wirken bei dem parallelen Knöchel zwei Motoren gemeinsam an der Nick- und Rollbewegung des Fußes mit, wobei keiner der beiden Motoren allein eine bestimmte Richtung steuert.
Das Gelenkmodul verfügt zudem über eine Schellenmontage und ein Hohlkabelrouting, was die Demontage erleichtert und Störungen der Kabel bei der Bewegung verringern kann.
Für normale Nutzer bleiben diese Dinge im Gehäuse des Roboters verborgen. Aber genau diese Details sind es, die Forscher interessieren.
Warum ist das Gelenk so angeordnet? Was würde sich ändern, wenn man einen anderen Aktor verwendet? Und wie müsste das Regelungssystem nach einer Anpassung des Mechanismus angepasst werden?
Derzeit,RP1 hat Ressourcen wie URDF, MJCF und Mesh-Modelle veröffentlicht.。Entwickler können die Verbindungsbeziehungen zwischen den Gelenken und Gliedern des Roboters einsehen, was für Simulations- und Bewegungssteuerungsforschung nützlich ist.
Die Unterlagen zum mechanischen Design betreffen auch die Anordnung der Gelenkachsen, den Bewegungsumfang, die Montageweise und die elektrische Architektur.
Was tiefer liegende Unterlagen wie CAD-Dateien, BOM und Leiterplatten-Fertigungsdateien betrifft, so handelt es sich dabei teilweise noch um interne Entwicklungsunterlagen; der genaue Umfang der Freigabe ist dem Projektrepository zu entnehmen.
Gelenke sind für die Ausführung von Bewegungen zuständig, aber wann Kraft eingesetzt und in welchem Winkel gedreht wird, entscheiden sie nicht selbst – das bestimmt das Steuerungssystem.
Die Embedded-Software des RP1 verbindet über Geräteabstraktion und einheitliche Schnittstellen Hardware wie Motoren, Trägheitssensoren und Batteriemanagementsysteme.
Die obere Algorithmusschicht erzeugt Gelenkziele, die untere Treiberschicht ist für Kommunikation und Ausführung zuständig und gibt die Gelenkzustände anschließend zurück.
Die zugehörige Software verwendet eine Regelungsfrequenz von 500 Hz und eine Strategie-Aktualisierungsfrequenz von 50 Hz. Entwickler können über eine einheitliche Gelenkbefehlsschnittstelle die Beziehung zwischen Regelung und Geräte-Rückmeldung erforschen.
Damit ein Roboter neue Bewegungen erlernen kann, benötigt er auch Trainingswerkzeuge.
RoboParty auchDas Tool hhtools (human-humanoid-tools) zur Retargeting von menschlichen Bewegungen wurde veröffentlicht.
hhtools mappt zunächst menschliche Bewegungen auf die Roboterstruktur ab, korrigiert die Bewegungen anschließend unter Berücksichtigung von Randbedingungen wie Gelenkbegrenzungen und Bodenkontakt und erzeugt so Bewegungsbahnen, die der Roboter verwenden kann.
hhtools Umleitungsbeispiele: Transportieren, Tanzen, Stufen und Hindernisse
Diese Daten können in den Simulationstrainingsprozess eingespeist werden; nach Strategielernen und Parameteranpassung werden sie anschließend auf realen Robotern zur Verifizierung eingesetzt.
Entwickler können die Aktionszuordnung sowie die Trainings- und Bereitstellungsschritte untersuchen und eigene Steuerungsstrategien ausprobieren.
Wie ein Roboter eine Bewegung erlernt, daran können sich auch Entwickler beteiligen.
Nach bekannten Informationenbaut RoboParty außerdem die offene Entwicklungsplattform PartyOS auf.
Derzeit ist ein Teil von System0, der grundlegenden Bewegungssteuerung, und der zugehörigen Infrastruktur bereits als Open Source veröffentlicht, darunter Projekte wie hhtools, MimicLite und UFO. UFO widmet sich der Forschung zu Störungserholung und Aufstehen nach Stürzen und bietet mehrere Roboterkonfigurationen, darunter RP1, an.
System1 und System2 für Absichtsrepräsentation und Agenten-Fähigkeitsorchestrierung befinden sich hingegen noch in der Forschungsphase.
Damit Algorithmen auf echter Hardware laufen können, muss auch der Alltagsexperimentbetrieb mithalten.
RP1etabliert Erfassungs- und Aufzeichnungsprozesse für Roboterzustände, Sensordaten und Aktionsdatenund hilft Entwicklern, die Entsprechung zwischen Daten und Steuerungsbefehlen zu überprüfen.
Hot-Swap-Akkuwechsel, modulare Demontage, standardisierte Wartung sowie verschiedene Kopf-, Endeffektor- und Rechenleistungs Konfigurationen erleichtern zudem kontinuierliche Experimente.
RP1-Handgelenkschnittstelle mit drei austauschbaren Endwerkzeugen
Schließlich können leerer Akku, beschädigte Teile oder notwendige Umbauten die Experimente jederzeit zum Stillstand bringen.
Nur wenn Entwickler etwas verändern, in Betrieb nehmen und wiederholt verifizieren können, hat eine offene Plattform einen echten Entwicklungswert.
Erst wenn die technische Blackbox geöffnet ist, beginnt das Ökosystem gerade erst
Die Robotikbranche profitiert seit vielen Jahren von Open Source.
Open-Source-Werkzeuge wie ROS haben vielen Entwicklern den Aufwand erspart, Software-Infrastruktur immer wieder von Grund auf neu aufzubauen.
Heute dringt Open Source zunehmend in mechanische Strukturen, Gelenke, Elektrik und Steuerungssysteme vor, sodass Technologien, die bisher in den Händen der Hersteller lagen, die Chance haben, zu gemeinsam genutzten Grundressourcen der Branche zu werden.
Vor dem RP1 hatteRoboParty bereits den Open-Source-Roboter RPO vorgestellt. Das Projekt erhielt auf GitHubetwa 2600 Starsund zog eine Reihe von Interessenten an.
Mit der Veröffentlichung des RP1 erstreckt sich der offene Bereich nun weiter auf die gesamte Entwicklungskette des Gesamtsystems.
RoboParty hat rund um dieses System drei aufeinander abgestimmte Komponenten aufgebaut.
- Open Body: stellt den Roboter-Körper und Hardware-Ressourcen bereit, einschließlich RPO, RP1, ROMOMO-Gelenke und RP Hand.
- PartyOS: verbindet Entwicklungswerkzeuge für Bewegungssteuerung, Wahrnehmungsinteraktion und Whole-Body-Operation, wobei sich einige Projekte noch in laufender Entwicklung befinden.
- Developer Ecosystem: richtet sich an Einzelentwickler, universitäre Forschungsteams und Embodied-Model-Unternehmen und hofft, mehr Menschen zur Beteiligung an der technischen Entwicklung und Vervollkommnung anziehen zu können.
Wie kann man mit diesem Paket arbeiten?
Zum Beispiel kann ein Modellunternehmen, das eine neue Bewegungssteuerungsstrategie trainiert hat, versuchen, diese auf dem RP1 zu validieren; Forschende einer wissenschaftlichen Einrichtung, die ein Gelenk oder ein Steuerungsmodul verbessert haben, haben ebenfalls die Möglichkeit, auf bestehenden Entwürfen weiterzuentwickeln.
Auch wenn die Forschungsrichtungen aller verschieden sind, haben alle die Chance, zugrunde liegende Ressourcen wiederzuverwenden, weniger Zeit für die Hardware-Anpassung aufzuwenden und die Energie für die Probleme zu sparen, die sie wirklich lösen wollen.
Das ist besonders wichtig für die Embodied-Intelligence-Branche.
Derzeit steht die Bewertung von Robotermodellen noch vor Problemen wie großen Hardware-Unterschieden und uneinheitlichen Testbedingungen. Bei derselben Aufgabe kann sich die Erfolgsquote ändern, sobald man einen anderen Roboter verwendet.
Wenn mehr Teams Experimente rund um stabile Hardware-Versionen, Trainingswerkzeuge und Teststandards durchführen, erhalten die Forschungsergebnisse eine vergleichbarere Referenz, und technische Errungenschaften lassen sich von Nachfolgern leichter validieren und verbessern.
Aber Open Source ist nur der Anfang.
Sind die Unterlagen vollständig? Kann das Repository dauerhaft gepflegt werden? Was geschieht, wenn es Probleme mit der Hardware gibt? Können Entwickler problemlos reproduzieren und ändern? Und erlaubt die Lizenz überhaupt Weiterentwicklung und kommerzielle Nutzung?
Das sind alles Prüfungen, an denen ein Open-Source-Projekt nicht vorbeikommt.
Von RPO bis RP1 hat RoboParty den Rahmen für offene Körper, Software-Werkzeuge und Entwickler-Ökosystem bereits aufgelegt.
Ob daraus wirklich ein Ökosystem entsteht, hängt davon ab, wie viele Entwickler sich künftig beteiligen und wie viele konkrete Ergebnisse sich ansammeln.
Für die gesamte Branche könnte die Bedeutung dieser Sache größer sein als die Veröffentlichung eines weiteren Open-Source-Roboters.
Die Entwicklungshürden für humanoide Roboter waren immer hoch. Mechanik, Elektronik, Steuerung, Algorithmen – jeder Bereich braucht Fachkräfte und langfristige Investitionen.
Selbst wenn man nur eine neue Idee validieren will, muss man möglicherweise zuerst viel Zeit in den Aufbau einer Basisplattform investieren.
Open Source gibt Nachfolgern die Chance, auf bereits erzielten Ergebnissen weiterzuforschen, und ermöglicht es, dass ein und dieselbe Technologie von verschiedenen Teams wiederholt validiert, verbessert und weitergeführt werden kann.
Natürlich bedeutet die Veröffentlichung von Plänen und Code nicht, dass Hardware-Kosten und technische Schwierigkeiten damit verschwinden. Um wirklich ein Ökosystem zu bilden, braucht es laufende Pflege und Beiträge.
Nur: Je mehr grundlegende Technologien erforscht, verändert und wiederverwendet werden können, desto mehr kann die Branche der humanoiden Roboter vielleicht das Rad weniger oft neu erfinden und mehr Gelegenheiten zur Erkundung neuer Technologien gewinnen.
Die Richtungen, die ein einzelnes Unternehmen erkunden kann, sind letztlich begrenzt.
Nur wenn man die Blackbox der Technik öffnet, entsteht die Chance, dass mehr Menschen mitmachen und den humanoiden Roboter gemeinsam voranbringen.
Anhang: RP1 Open-Source-Ressourcen und Informationen zum geschlossenen Test
[1]RP1-Entwicklungsressourcen:
https://github.com/Roboparty/RP1
[2]Technisches Whitepaper:
https://roboparty.com/documents/roboto-01
Derzeit hat RoboParty Anmeldungen für den geschlossenen Gemeinschaftstest des RP1 geöffnet, gerichtet an Entwickler und Teams mit konkreten Projektanforderungen, die bereit sind, sich kontinuierlich an der Produktiteration zu beteiligen. Teilnehmer können Probleme rückmelden, Issues einreichen und den Sonderpreis für den gemeinsamen geschlossenen Test genießen.
Anmelde-Einstieg:
https://roboparty.com/beta/RP1