Sind städtische Dienstleistungen zum neuen Prüfstand der verkörperten Intelligenz geworden?

Derselbe Roboter steht in einer Fabrikhalle und auf einer städtischen Straße praktisch vor zwei völlig unterschiedlichen Welten.

In strukturierten Umgebungen (z. B. Fabrikhallen) ist der Einsatz von Robotern bereits sehr ausgereift. Sobald sie jedoch in offene Umgebungen (z. B. städtische Straßen) eintreten, steigt der Schwierigkeitsgrad massiv an. Insbesondere in städtischen Außenbereichen müssen Roboter 7 Tage die Woche rund um die Uhr ohne Unterbrechung arbeiten, was erfordert, dass sie Wind und Sonne sowie den Verkehr von Fußgängern und Fahrzeugen problemlos standhalten.

Der Bericht zur Entwicklung der Embodied AI der China Academy of Information and Communications Technology fasst den aktuellen Stand in einem Satz zusammen: Es fehlt an einem geschlossenen Kreislauf für Daten, Modelle, Hardware und Einsatzszenarien. Zweifellos hat die Embodied AI im Jahr 2026 bereits begonnen, die Phase der technischen Validierung zu verlassen und in die Phase der praktischen Umsetzung in Szenarien überzugehen. Städtische Dienstleistungen werden dabei zu einem wichtigen Prüfstein, der alle praktischen Umsetzungsfähigkeiten auf die Probe stellt.

Angesichts dieser Situation hat Kusa Technology, dessen Ziel es ist, „Embodied AI für offene städtische Szenarien einzusetzen“, eine klare Entscheidung getroffen: Das gesamte Stack-Engineering von Datenerfassung über Modelltraining bis hin zur Roboterbereitstellung wird vollständig abgedeckt, damit Roboter in der realen Welt zuerst in Betrieb genommen werden können und stabil laufen. Nach Einschätzung von Kusa müssen sowohl die Forschungs- und Entwicklungsfähigkeiten als auch die Engineering-Fähigkeiten auf hohem Niveau sein, um die Lücke zur großflächigen Umsetzung zu schließen.

Kusa wurde 2023 gegründet. Das Kernteam stammt von Universitäten wie der Tsinghua-Universität und der Shanghai Jiao Tong-Universität. Die Kernmitglieder verfügen über 15 Jahre Erfahrung in der Forschung, Entwicklung und Verwaltung von Fahrzeugen, Robotern und autonomen Fahrsystemen. Das Kernprodukt sind Dienstleistungsroboter für offene städtische Szenarien, die bereits in mehr als 40 Städten im Einsatz sind.

Mitte Juli dieses Jahres veröffentlichte Kusa Technology eine Embodied AI-Entwicklungsplattform namens Kusa Robo Platform. Die Plattform hat eine klare Positionierung: Sie ist eine Engineering-Plattform, die speziell für den stadtweiten Einsatz von Embodied AI entwickelt wurde und einen vollständigen geschlossenen Kreislauf von Datenerfassung, Modelltraining über die Bereitstellung auf mehreren Endgeräten bis hin zum Fernbetrieb und zur Wartung bildet. Als eines der wenigen Unternehmen, die diesen Prüfstein wirklich betreten haben, möchte Kusa damit eine Frage beantworten, die in der Branche noch niemand eindeutig beantworten konnte:

Warum ist die Entwicklung einer spezialisierten Plattform der Schlüssel zur großflächigen Umsetzung von Embodied AI?

01.  Stadtweite Embodied AI – warum ist sie so schwierig?

Teams für autonomes Fahren, die auf Roboter umsteigen, glauben fast zu Beginn, dass sie lediglich ein zweidimensionales Problem auf ein dreidimensionales Niveau heben müssen.

Das Team von Kusa dachte zu Beginn genauso. Der Übergang von der Ebene zum Raum schien nicht besonders schwierig zu sein. Erst als sie sich wirklich in die Szenarien vertieften, stellten sie fest, dass die grundlegenden Bedingungen sich vollständig geändert haben.

Der wesentlichste Unterschied liegt in der veränderten Bewertungsmethode. In demselben Szenario besteht die Aufgabe eines Pkws darin, von Punkt A zu Punkt B zu gelangen – ohne Kollision und mit gutem Fahrkomfort gilt dies als Erfolg. Bei einem städtischen Reinigungsroboter ist es oft umgekehrt: Er muss aktiv mit verschiedenen Objekten in Kontakt treten und entsprechende Entscheidungen treffen.

Nehmen wir als Beispiel eine prall gefüllte schwarze Plastiktüte auf der Straße: Ist darin ein Ziegelstein, eine mit Wasser gefüllte Mineralwasserflasche oder eine leere Flasche? Die erforderliche Vorgehensweise unterscheidet sich in allen Fällen massiv. Für das autonome Fahren reicht es aus, darüber zu fahren oder auszuweichen. Ein Reinigungsroboter muss versuchen, den Gegenstand aufzukehren, und erst dann entscheiden, wie er weiter vorgeht, falls er ihn nicht bewegen kann. Denn das harte Kriterium für die Reinigung ist, den Müll vollständig zu beseitigen – wenn er jedem Objekt ausweicht, hat er seine Aufgabe überhaupt nicht erfüllt.

Die veränderte Bewertungsmethode verbirgt eine unterschätzte Dimension und Schwierigkeit: die physische Interaktion.

Tao Sheng, Mitbegründer und CTO von Kusa Technology, erklärte gegenüber 36Kr, dass sich das autonome Fahren kaum für die Kontaktmechanik interessiert, da die Automobilindustrie über langjährige Erfahrungen verfügt und das Fahrgestell „schon längst ausgereift“ ist. Städtische Dienstleistungsroboter müssen hingegen das Drehmoment-Feedback und die Drehsteuerung der endständigen Reinigungsstruktur vollständig mit der Steuerung des gesamten Fahrzeugs koppeln. Genau hier liegt der Unterschied beim Übergang vom „Fahrzeug“ zum „Roboter“. Um physische Interaktionen gut zu bewältigen, reichen Sensoren allein nicht aus – das Modell muss die physische Welt selbst verstehen.

02. Warum wurde ausgerechnet das städtische Szenario gewählt?

Laut Tao Sheng liegt die Kernüberzeugung in der Erkenntnis eines realen und dringenden Bedarfs:

Städtische Räume weisen eine hohe Komplexität und starke technische Barrieren auf und erzeugen gleichzeitig direkt umsetzbare kommerzielle Werte. Sie sind der am besten geeignete Nährboden, um die Engineering-Fähigkeiten von Embodied AI zu validieren. Noch wichtiger ist, dass die Marktdurchdringung in der Branche der städtischen Dienstleistungsroboter mit weniger als 1 % sehr gering ist – es handelt sich um einen noch zu erschließenden blauen Ozean.

Ein Geschäft, das schwer umzusetzen ist, aber klare Erträge bringt, ist auch eine „schwierige, aber richtige Sache“, die langfristige technische Investitionen wert ist. Diese Hürden erfordern eine spezielle Engineering-Plattform für stadtweite Embodied AI. Kusa bietet die Antwort mit der Kusa Robo Platform, wobei zunächst drei Kerntechnologien erläutert werden müssen.

03. Basis, Treibstoff und Gehirn

Die drei neu vorgestellten Kerntechnologien haben jeweils klar definierte Aufgaben.

Kusa OS ist ein spezialisiertes Betriebssystem für stadtweite Embodied AI, das für den stabilen Betrieb und die Echtzeitplanung der Roboter zuständig ist. Corner Factory ist eine Datenfabrik, die automatisch Langschwanz-Szenarien aus Daten extrahiert, bereinigt und kennzeichnet. Kusa Omni-CTS ist ein allmodales Embodied-Modell, das die gesamte Kette von der Szenarienwahrnehmung über die kognitive Verarbeitung bis hin zur Aktionsausgabe abdeckt. Alle drei Technologien beantworten dieselbe Frage: Wie können Roboter in der Stadt stabil laufen, schnell lernen und die Szenarien verstehen?

Das erste Problem, das Kusa OS löst, ist das „stabile Laufen“. Die Ursprünge dieses Betriebssystems gehen auf das Jahr 2018 zurück, als das Kernteam von Kusa noch an autonomen Fahrzeugen für Hafenbereiche arbeitete.

ROS2 ist das am weitesten verbreitete Open-Source-Software-Framework in der Roboterbranche. Es ist auf Flexibilität und Benutzerfreundlichkeit ausgelegt, sodass Forscher neue Algorithmen schnell testen können. Der Nachteil ist jedoch die unzureichende harte Echtzeitfähigkeit, die zu unvorhersehbaren Verzögerungen und Jitter führt. Dies birgt potenzielle Risiken in städtischen Dienstleistungsszenarien mit sehr hohen Anforderungen an langfristige Stabilität und Echtzeitverhalten.

Genau das ist der Hauptgrund, warum Kusa Kusa OS von Grund auf selbst entwickelt hat.

Genau wie städtische Dienstleistungen erfordern auch Hafenszenarien einen 7-tägigen Rund-um-die-Uhr-Betrieb ohne Unterbrechung und sehr hohe Anforderungen an langfristige Stabilität und Echtzeitverhalten. Ausgehend von den echten Anforderungen der Szenarien hat Kusa auf Basis von Datenverteilungstechnologien ein System von Grund auf neu entwickelt. Der Kerngedanke ist, das System schlanker zu gestalten und jedes Modul streng kontrollierbar zu machen. Ein kleineres System ist stabiler.

Im Laufe langjähriger Iterationen hat das System drei Probleme der Branche gelöst: langfristige Stabilität, deterministische Planung und die Reduzierung von Latenzjitter.

In den letzten Jahren war der Aufwand für die Eigenentwicklung eines Betriebssystems aber auch sehr hoch.

„Bis heute hadere ich immer noch damit“, beschreibt Tao Sheng die Situation. Die größte Herausforderung ist die unvollständige Toolchain. Die ROS2-Community verfügt über zahlreiche Open-Source-Beiträge, die die gesamte Kette von der Echtzeit-Visualisierungsüberwachung über die Roboterdynamiksimulation bis hin zur Rekonstruktion von Weltszenarien abdecken. Bei einer Eigenentwicklung muss all dies selbst aufgebaut werden. Kusa hat die Lösung gewählt, eine eigene Programmier-Toolchain zu entwickeln, die Initialisierungscode automatisch in beschreibender Sprache generiert, um die Migrationskosten so gering wie möglich zu halten.

Der Aufwand für die Eigenentwicklung hat letztendlich Freiheiten auf unterster Ebene sowie Echtzeitstabilität gebracht.

Wenn das Betriebssystem die Basis darstellt, ist Corner Factory der Treibstoff, da es das Problem des „kontinuierlichen Lernens“ löst.

Der Daten-Flywheel von Kusa ist vollständig funktionsfähig: Als das erste Serienprodukt des Unternehmens in Betrieb ging, war die gesamte Pipeline bereits vollständig aufgebaut. Der Anteil der automatischen Kennzeichnung ist von anfänglichen 80 % auf über 90 % gestiegen.

Laut Tao Sheng funktioniert die vollständige Datenkette wie folgt: Wenn der Roboter während des Betriebs auf eine Anomalie stößt und anhält, speichert er automatisch die Daten mehrerer Sensoren für einige Sekunden vor und nach dem Vorfall. Nach der Rückkehr zum Einsatzort werden die Daten von einem speziellen Datensammler an die Datenfabrik übermittelt. Zuerst werden Gesichter, Kennzeichen und andere sensible Daten anonymisiert, bevor die automatische Kennzeichnung beginnt – die von der anfänglichen 2D-Segmentierung und -Klassifizierung auf 3D-Belegungsgitter und 3D-Rekonstruktion aktualisiert wurde. Menschen führen die abschließende Korrektur und Bestätigung durch, bevor ein spezialisiertes Modell auswählt, welche Langschwanz-Szenarien wirklich lernenswert sind. Diese werden in die Datenbank aufgenommen und für das Modelltraining verwendet.

In Corner Factory generiert Kusa Omni-CTS basierend auf der Eingabe eines Einzelbilds eines realen Szenarios einen sequenziellen Videostream und leitet daraus synchron 3D-Punktwolken und OCC-semantische Belegungsinformationen ab. Kusa Omni-CTS legt OCC/3D-Punktwolken als zentrale Zwischenrepräsentation fest und baut physische räumliche Beschränkungen zwischen 2D-Beobachtungen und 3D-Strukturen auf, um die Genauigkeit der räumlichen Verständnis sicherzustellen und den effizienten Betrieb des geschlossenen Datenkreislaufs sowie wöchentliche Modelliterationen zu unterstützen.

Tao Sheng sagt aber auch offen: „Der Daten-Flywheel oder die Pipeline sind keine Barrieren – die Daten selbst sind die echte Barriere. Denn Daten hängen sehr stark von den Szenarien ab: Was man nie gesehen hat, hat man einfach nie gesehen, das kann man sich nicht von Ingenieuren ausdenken. Der Vorsprung durch den Daten-Flywheel ergibt sich im Wesentlichen aus der Multiplikation von Zeit und Datenmenge.“

Das oberste Omni-CTS als Gehirn löst das Engineering-Problem, dass Roboter die Szenarien verstehen.

Laut Tao Sheng lautet das „erste Prinzip“ des Kusa-Modells: Die Schwierigkeit liegt nicht in einer bestimmten Technologie, sondern in der Veränderung der Denkweise. Er macht sogar einen selbstironischen Witz: „Wir sind ein Flickwerk aus verschiedenen Teilen“. Aber dieses Flickwerk ist kein zufälliges Zusammensetzen: Es kombiniert fortschrittliche Ideen aus verschiedenen Bereichen wie Videogenerierung, Raum-Zeit-Kodierung und 3D Gaussian zu einer originellen Lösung.

Im Engineering-Bereich gibt es eine genauere Bezeichnung dafür: Es handelt sich um eine Innovation der Modellarchitektur, die die Schwierigkeit der asynchronen Eingabe von Daten in das Modell überwindet.

Das Kernproblem ist sehr konkret. Bei echten Robotern lassen sich mehrere Sensoren von Natur aus nicht perfekt synchronisieren. Beispielsweise läuft das Lidar mit 10 Hz, die Kamera mit 30 Hz und das IMU möglicherweise mit 1000 Hz – die Daten kommen in völlig unterschiedlichen Rhythmen an. Eine erzwungene Synchronisation führt entweder zu Verzögerungen und Staus oder zu widersprüchlichen Daten, was die Modellleistung massiv verschlechtert.

Kusa Omni-CTS löst genau dieses Problem mit einer zweistufigen Lösung:

Erstens: Die asynchrone Merkmalsausrichtung über verschiedene Modalitäten hinweg. Anstatt traditionelle diskrete Frames auszurichten, werden kontinuierliche Raum-Zeit-Kurven im hochdimensionalen latenten Raum aufgebaut. Visuelle Daten, Lidar-Daten, IMU-Daten und Drehmoment-Feedback-Daten werden jeweils in ihrem eigenen Rhythmus erfasst und richten sich im Modell automatisch aus, sodass die Daten natürlich fließen, ohne auf teure Hardware-Synchronisation angewiesen zu sein.

Zweitens: Die Vorhersage der physischen Konsistenz – dies ist genau die Antwort auf das Problem der „physischen Interaktion“. Im hochdimensionalen Raum werden kontinuierliche Trajektorien aufgebaut, die der physischen Dynamik entsprechen. Das Modell versteht nicht nur, was gerade passiert, sondern kann basierend auf physikalischen Gesetzen und Umgebungsänderungen im Voraus verschiedene mögliche zukünftige Situationen vorhersagen und dann die sinnvollste Ausführungsart auswählen.

Strukturdiagramm