Städtische Dienstleistungen – ein neues Prüffeld für Embodied Intelligence?

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

In strukturierten Szenarien (z. B. Fabrikhallen) ist der Einsatz von Robotern bereits sehr ausgereift. Sobald sie jedoch in offene Umgebungen (z. B. städtische Straßen) gelangen, steigt die Schwierigkeit drastisch an. Insbesondere in städtischen Außenbereichen müssen Roboter 7×24 Stunden ohne Unterbrechung arbeiten – das erfordert, dass sie Wind, Sonne, Regen und den ständigen Verkehr von Fahrzeugen und Menschen standhalten.

Der „Entwicklungsbericht für Embodied AI“ der Chinesischen Akademie für Informations- und Kommunikationstechnologie fasst den aktuellen Zustand in einem Satz zusammen: Daten, Modelle, Hardware und Szenarien können kaum einen geschlossenen Zyklus bilden. Dennoch steht fest: Die Embodied AI im Jahr 2026 hat die Phase der technischen Validierung verlassen und tritt in die Phase des praktischen Szenarioeinsatzes ein. Städtische Dienstleistungen werden dabei zu einem wichtigen Prüfstand, der alle Fähigkeiten zur praktischen Umsetzung auf die Probe stellt.

Angesichts dieser Situation hat Kusa Technology, das sich das Ziel gesetzt hat, „Embodied AI für offene städtische Szenarien zu nutzen“, eine klare Entscheidung getroffen: Die gesamte Engineering-Kette von Datenerfassung, Modelltraining bis hin zum Roboter-Einsatz wird durchgängig vernetzt, damit Roboter in der realen Welt zuerst in Betrieb gehen und stabil laufen können. Nach Kusas Einschätzung müssen sowohl die Forschungs- und Entwicklungsfähigkeiten als auch die Engineering-Fähigkeiten gleichzeitig auf hohem Niveau sein, um die Kluft zum großflächigen Einsatz zu überbrücken.

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 ist ein Dienstroboter für offene städtische Szenarien, der bereits in mehr als 40 Städten im Einsatz ist.

Mitte Juli dieses Jahres veröffentlichte Kusa Technology die Embodied AI-Entwicklungsplattform „Kusa Robo Platform“. Die Plattform hat eine klare Positionierung: Sie ist eine speziell für den stadtweiten Einsatz von Embodied AI entwickelte Engineering-Plattform, die einen vollständigen geschlossenen Zyklus von Datenerfassung, Modelltraining über die Bereitstellung auf mehreren Endgeräten bis hin zum Fernbetrieb bildet. Als eines der wenigen Unternehmen, das tatsächlich diesen „Prüfstand“ betritt, möchte Kusa eine Frage beantworten, die in der Branche bisher niemand klar formulieren konnte:

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

01. Warum ist stadtweite Embodied AI so schwierig?

Teams, die vom Bereich des autonomen Fahrens zu Robotern wechseln, glauben fast alle zuerst, sie müssten nur ein 2D-Problem in ein 3D-Problem umwandeln.

Auch das Kusa-Team dachte anfangs so. Die Umstellung von der Ebene auf den Raum schien nicht sehr schwierig zu sein – aber als man sich wirklich in die Szenarien vertiefte, stellte sich heraus, dass die Grundvoraussetzungen völlig anders sind.

Der wesentlichste Unterschied liegt in der veränderten Bewertungsmethode. In demselben Szenario ist die Aufgabe eines Pkws, von A nach B zu gelangen, ohne zu kollidieren und mit angenehmem Fahrgefühl – das zählt als Erfolg. Ein städtischer Reinigungsroboter hingegen verhält sich umgekehrt: Er muss aktiv mit verschiedenen Objekten in Kontakt treten und Urteile fällen.

Beispielsweise ist ein prall gefüllter schwarzer Plastiksack auf der Straße – ist darin ein Ziegelstein, eine mit Wasser gefüllte Mineralwasserflasche oder eine leere Flasche? Die erforderlichen Maßnahmen unterscheiden sich drastisch. Für das autonome Fahren reicht es, darüber zu fahren oder auszuweichen. Ein Reinigungsroboter muss versuchen, den Sack zu kehren, und erst dann entscheiden, was zu tun ist, wenn er ihn nicht bewegen kann. Denn die harte Anforderung der Reinigungsarbeit ist es, den Müll vollständig zu beseitigen – wenn er vor allem ausweicht, hat er praktisch gar nicht gearbeitet.

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

Tao Sheng, Mitbegründer und CTO von Kusa Technology, sagte zu 36Kr: Beim autonomen Fahren spielt die Kontaktmechanik kaum eine Rolle, da die Automobilindustrie über jahrelange Erfahrungen verfügt und das Fahrgestell „schon lange ausgereift“ ist. Städtische Dienstroboter hingegen müssen das Drehmoment-Feedback und die Rotationssteuerung der Reinigungsstruktur am Ende vollständig mit der Fahrzeugsteuerung koppeln. Der Sprung vom „Fahrzeug“ zum „Roboter“ liegt genau hier. Um die physische Interaktion gut zu beherrschen, reichen Sensoren allein nicht aus – das Modell muss die physische Welt selbst verstehen.

02. Warum ausgerechnet städtische Szenarien wählen?

Tao Sheng erklärt, die Kernüberzeugung liege in der Erkenntnis einer realen und dringenden Nachfrage:

Städtische Räume sind komplex, haben hohe technische Hürden und können gleichzeitig direkt kommerziellen Nutzen bringen. Sie sind der geeignetste Nährboden, um die Engineering-Fähigkeiten von Embodied AI zu validieren. Noch wichtiger ist: Die Marktdurchdringung von städtischen Dienstrobotern ist extrem niedrig – sie liegt unter 1 % – und stellt einen noch unerschlossenen „blauen Ozean“ dar.

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 machen deutlich: Für stadtweite Embodied AI braucht es eine spezielle Engineering-Plattform. Kusas Antwort darauf ist die Kusa Robo Platform – und dazu müssen zuerst drei Kerntechnologien erläutert werden.

03. Basis, Treibstoff und Gehirn

Die drei neu vorgestellten Kerntechnologien haben jeweils klare Aufgabenbereiche.

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 Langschwanzszenarien aus Daten extrahiert, bereinigt und annotiert. Kusa Omni-CTS ist ein multimodales Embodied-Modell, das die gesamte Kette von Szenariowahrnehmung, kognitivem Verständnis bis hin zu Aktionsausgabe abdeckt. Alle drei Technologien beantworten dieselbe Frage: Wie können Roboter in der Stadt stabil laufen, schnell lernen und Szenarien verstehen?

Kusa OS löst zuerst das Problem des „stabilen Laufens“. Die Entwicklung dieses Betriebssystems geht zurück auf das Jahr 2018, als das Kusa-Kernteam noch an fahrerlosen Transportsystemen für Häfen arbeitete.

ROS2 ist das beliebteste Open-Source-Software-Framework im Roboterbereich. Es ist auf Flexibilität und Benutzerfreundlichkeit ausgelegt, sodass Forscher neue Algorithmen schnell testen können – aber der Nachteil ist die unzureichende harte Echtzeitfähigkeit, die zu unvorhersehbaren Verzögerungen und Jitter führt. In städtischen Dienstszenarien mit sehr hohen Anforderungen an langfristige Stabilität und Echtzeit birgt das potenzielle Risiken.

Das ist auch der Hauptgrund, warum Kusa Kusa OS von Grund auf eigenentwickelt hat.

Wie städtische Dienstleistungen erfordern auch Hafenszenarien einen 7×24-Stunden-Betrieb ohne Unterbrechung und stellen höchste Anforderungen an langfristige Stabilität und Echtzeit. Ausgehend von den echten Anforderungen der Szenarien hat Kusa auf Basis von Datenverteilungstechnologien ein System komplett neu entwickelt. Der Kerngedanke ist, das System schlanker zu gestalten, sodass jedes Modell streng kontrollierbar ist. Ein kleineres System ist stabiler.

Im Laufe der langfristigen Iterationen hat das System drei Probleme der Branche gelöst: langfristige Stabilität, deterministische Planung und Kompression von Verzögerungsjitter.

Dennoch waren die Kosten der Eigenentwicklung eines Betriebssystems in den vergangenen Jahren spürbar.

„Bis heute hadere ich noch damit“, beschreibt es Tao Sheng. Die größte Herausforderung ist die unvollständige Werkzeugkette. Die ROS2-Community bot ursprünglich eine Fülle von Open-Source-Beiträgen, die die gesamte Kette von Echtzeit-Visualisierungsüberwachung über Robotik-Dynamiksimulation bis hin zur 3D-Welterstellung abdecken – bei einer Eigenentwicklung muss all das selbst aufgebaut werden. Kusas Lösung war, einen neuen Weg zu gehen: eine eigene Programmierwerkzeugkette zu entwickeln, die mit beschreibender Sprache automatisch Initialisierungscode generiert und die Migrationskosten so gering wie möglich hält.

Die Aufwendungen für die Eigenentwicklung haben sich am Ende ausgezahlt: Sie brachten Freiheit auf unterster Ebene und Echtzeitstabilität.

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

Der Daten-Flywheel von Kusa hat sich erfolgreich etabliert: Als das erste Serienprodukt des Unternehmens in Betrieb ging, war die gesamte Datenpipeline bereits funktionsfähig. Heute liegt der Anteil der automatischen Annotation bei über 90 %, gegenüber 80 % in der Anfangsphase.

Laut Tao Sheng funktioniert die vollständige Datenkette so: Wenn ein Roboter während der Arbeit auf eine ungewöhnliche Situation stößt und stoppt, speichert er automatisch die Multisensordaten der vorherigen und folgenden Sekunden. Nach der Rückkehr zur Arbeitsstelle werden die Daten von einem speziellen Erfassungsgerät an die Datenfabrik übermittelt. Zuerst werden Gesichter, Kennzeichen und andere sensible Daten anonymisiert, dann folgt die automatische Annotation – von der frühen 2D-Segmentierung und -Klassifizierung wird auf 3D-Belegungsgitter und 3D-Rekonstruktion umgestellt. Nach der manuellen Überprüfung und Vervollständigung wählt ein spezialisiertes Modell die wirklich lernwichtigen Langschwanzszenarien aus, die in die Datenbank aufgenommen und für das Modelltraining verwendet werden.

In der Corner Factory generiert Kusa Omni-CTS basierend auf einem einzelnen Frame eines echten Szenarios einen zeitlichen Videostrom und leitet daraus synchron 3D-Punktwolken und OCC-semantische Belegungsdaten ab. Kusa Omni-CTS definiert OCC/3D-Punktwolken als zentrale Zwischenrepräsentation, baut eine physikalische Raumrestriktion zwischen 2D-Beobachtungen und 3D-Strukturen auf, gewährleistet die Genauigkeit des Raumverständnisses und unterstützt den effizienten Betrieb des geschlossenen Datenzyklus sowie wöchentliche Iterationen des Modells.

Aber Tao Sheng betont auch offen: „Das Daten-Flywheel oder die Pipeline sind keine eigentlichen Hürden. Die Daten selbst sind die wahre Hürde. Denn Daten hängen extrem stark von den Szenarien ab – was man nie gesehen hat, kann man sich nicht einfach als Ingenieur vorstellen. Der Vorsprung, den ein Daten-Flywheel bringt, ergibt sich im Wesentlichen aus der Multiplikation von Zeit und Datenmenge.“

Das oberste Modul, Omni-CTS, fungiert als „Gehirn“ und löst das Engineering-Problem, dass Roboter „Szenarien verstehen“ können.

Tao Sheng erklärt, das „Erste Prinzip“ von Kusas Modell lautet: Die Schwierigkeit liegt nicht in einer einzelnen Technologie, sondern in der Veränderung der Denkweise. Er scherzt sogar selbstironisch: „Wir sind ein Patchwork-Monster“. Aber dieses Patchwork ist keine zufällige Zusammenfügung – es kombiniert die fortschrittlichen Ideen verschiedener Bereiche wie Videogenerierung, raumzeitliche Kodierung und 3D-Gaussian zu einer originären Lösung.

Im Engineering-Bereich gibt es einen passenderen Ausdruck: Das ist eine Innovation der Modellstruktur – sie überwindet die Schwierigkeit der asynchronen Eingabe in Modellen.

Das Kernproblem ist konkret: Auf einem echten Roboter sind die Signale mehrerer Sensoren von Natur aus nicht synchron. Beispielsweise arbeitet ein Lidar mit 10 Hz, eine Kamera mit 30 Hz und ein IMU möglicherweise mit 1000 Hz – die Daten kommen völlig unterschiedlich zeitlich an. Eine erzwungene Synchronisation führt entweder zu Verzögerungen oder Widersprüchen, sodass die Modellleistung stark einbricht.

Kusa Omni-CTS löst genau dieses Problem – die Lösung gliedert sich in zwei Ebenen:

Erstens: Asynchrone Merkmalsausrichtung über verschiedene Modalitäten hinweg. Statt der traditionellen Ausrichtung diskreter Frames werden kontinuierliche raumzeitliche Kurven im hochdimensionalen latenten Raum aufgebaut. Sicht, Lidar, IMU und Drehmoment-Feedback werden jeweils in ihrem eigenen Rhythmus erfasst und „synchronisieren sich automatisch“, sobald sie in das Modell gelangen – sodass Daten natürlich fließen können, ohne auf teure Hardware-Synchronisation angewiesen zu sein.

Zweitens: Vorhersage der physikalischen Konsistenz – das ist genau die Antwort auf das Problem der „physischen Interaktion“. Im hochdimensionalen Raum werden kontinuierliche Trajektorien aufgebaut, die der physikalischen Dynamik entsprechen. Das Modell versteht nicht nur, was gerade passiert, sondern kann basierend auf physikalischen Gesetzen und Umgebungsänderungen auch vorhersehen, welche Situationen als Nächstes eintreten könnten – und dann die sinnvollste Handlung auswählen.

Strukturdiagramm des Kusa Omni-CTS-Modells: Ein multimodales Modell auf Basis kontinuierlicher raumzeitlicher Vorhersage

Aus hardwaretechnischer Sicht erfordert dieses Design kaum Änderungen an