Roboter-SDKs, ROS 2 und Simulationsumgebungen

Eine Roboterplattform des Jahres 2026 — ob humanoid oder vierbeinig — bringt drei Software-Themen mit, die Sie klären müssen, bevor auch nur eine Zeile Ihres eigenen Codes läuft. Das Hersteller-SDK, das mit den Gelenken spricht. Der ROS-2-Wrapper, der mit allem anderen spricht. Und der Simulator, den Sie einsetzen, weil einen Unitree G1 EDU für 43k $ gegen die Wand zu fahren eine teure Art ist, einen Tippfehler zu finden.

Diese drei Schichten sind nicht austauschbar. Das SDK ist echtzeitfähig und proprietär. ROS 2 ist die Lingua franca, die den Robotik-Code des Rests der Welt auf Ihrer Plattform lauffähig macht. Der Simulator ist der Ort für all die Arbeit, die Sie am echten Roboter nicht machen wollen — Reinforcement Learning, großflächige Datengenerierung, Szenenentwurf, Headless-CI. Die meisten Teams investieren in alle drei zu wenig.

Dieser Artikel zeigt, was jede Schicht im Jahr 2026 tatsächlich leistet, wo die Grenzen verlaufen und welche Kombinationen sich mit einem realistischen Robotiklabor-Budget aufzubauen lohnen. Die Referenzplattformen sind jene aus R01 und R02. Die Referenz-Rechenleistung ist die Kentino AI Serie (4× oder 8× RTX 5090 bzw. RTX Pro 6000 Blackwell, EPYC- oder Xeon-Host).

Die SDK-Schicht — was Hersteller wirklich liefern

Jeder ernstzunehmende Roboterhersteller liefert ein Software Development Kit mit. Der Name ist überall derselbe, der Inhalt nicht. Das steckt tatsächlich drin.

Zwei Unterschiede wiegen schwerer als alle anderen.

Offen oder abgeschottet. Unitree, Booster, EngineAI und DeepRobotics geben Ihnen Zugriff auf Gelenkebene. Sie können Momentbefehle mit 500 Hz bis 1 kHz direkt an die Aktoren schicken. Genau das brauchen Sie für den Einsatz von RL-Policies, für eigene Lokomotionsforschung und für alles Dynamische. Boston Dynamics und ANYbotics halten die Gelenksteuerung geschlossen — Sie erhalten High-Level-Primitive (gehe dorthin, steige da hinauf, manipuliere dies), das SDK stellt diese als RPC-Aufrufe bereit, und der herstellereigene Controller erledigt die Gelenkarbeit. Das ist eine bewusste Entscheidung. Der geschlossene Stack ist zuverlässiger, und die Autonomie-Software ist genau das, wofür Sie 74k $ bis 200k $ zahlen. Für Forschung an der Low-Level-Regelung ist es trotzdem der falsche Stack.

Echtzeitfähig oder nicht. Unitree SDK2 nutzt Cyclone DDS über eine dedizierte Netzwerkschnittstelle und liefert Ihnen Umlaufzeiten im Sub-Millisekundenbereich auf der Gelenkschleife. Boosters Stack arbeitet ähnlich. Das Spot SDK setzt auf gRPC über HTTP/2 — bestens geeignet, um ein Verhalten anzustoßen, unbrauchbar, um einen Regelkreis mit 1 kHz zu schließen. Wenn Ihre Arbeit eine Schleife unter 2 ms braucht, zählt die Architektur mehr als die Sprache.

Eine Anmerkung zur Python-Frage. Jeder Hersteller bietet Python-Bindings an. Keines davon ist die Sprache, in der die Regelschleife läuft. Das Muster ist branchenweit identisch: C++ für den Echtzeit-Controller, Python für alles darüber. Die Hersteller-SDKs bilden das ab: Die C++-Bindings legen mehr offen, laufen schneller und sind die Sprache, in der die Beispiele des Herstellers geschrieben sind. Python-Bindings sind erstklassig für High-Level-Arbeit und ein Wrapper für den Low-Level-Pfad. Wählen Sie C++, wenn Sie die innere Regelschleife schreiben, und Python für Orchestrierung, Wahrnehmungs-Glue und die Anbindung an den Inferenzserver.

ROS 2 — warum am Ende alle darauf normalisieren

Das native SDK bringt Sie auf den Roboter. ROS 2 bringt Sie ins Ökosystem.

Es gibt drei Gründe, warum jede ernsthafte Integration am Ende ROS 2 spricht, selbst wenn das Hersteller-SDK ausreichen würde:

1. Interoperabilität. Ihr Wahrnehmungs-Stack, Ihr SLAM, Ihre Navigation, Ihr Manipulationsplaner, Ihre Teleoperation — für all das gibt es ROS-2-Implementierungen, gepflegt von Hunderten Beitragenden. Keine davon spricht nativ das DDS-Topic-Format von Unitree. Wrappen Sie das SDK einmal in ROS-2-Nachrichten, und das gesamte Ökosystem steht Ihnen offen.
2. Flotten mehrerer Hersteller. An dem Tag, an dem Sie einen zweiten Roboter eines anderen Herstellers hinzufügen, bricht der Native-SDK-Ansatz zusammen. ROS 2 ist die einzige Abstraktion, mit der sich ein Spot, ein ANYmal und ein G1 denselben Map-Server, denselben Task-Graph und dieselbe Mensch-Maschine-Schnittstelle teilen.
3. Personal. Menschen kennen ROS 2. Sie kennen nicht die Topic-Namenskonventionen von Unitree DDS. Ein Team, das auf ROS 2 aufbaut, kann weltweit rekrutieren. Ein Team auf einem proprietären Stack nicht.

Stand der ROS-2-Distributionen, Mai 2026:

Die ehrliche Einschätzung. Produktive Installationen laufen heute weiterhin auf Humble. Humble ist die LTS, auf die die Hersteller zielen — Unitrees unitree_ros2, Boosters Stack, das Community-Projekt spot_ros2 und ANYbotics' grid_map haben alle stabile Humble-Branches. Jazzy ist der Ausgangspunkt für neue Projekte: drei weitere Jahre LTS-Leben und ausgereiftes Migrationswerkzeug. Lyrical Luth ist zu jung für eine Festlegung — geben Sie ihr bis Ende 2026 Zeit, bevor Sie ein Produktivsystem darauf aufsetzen.

Wenn Sie im Mai 2026 ein Projekt beginnen, nehmen Sie Jazzy. Wenn Sie eines erweitern, das 2023 gestartet ist, bleiben Sie auf Humble, bis der nächste Roboterkauf die Migration erzwingt. Iron und Kilted können Sie komplett überspringen; Nicht-LTS-Releases sind für alle, die Gazebo-Harmonic-Upgrades eng verfolgen wollen und den Wartungsaufwand in Kauf nehmen.

Die Trennung der Regelschleifen

Das ist die Architekturentscheidung, die die meisten Teams kalt erwischt.

Die Trennung der Regelschleifen: unten die echtzeitfähige C++-SDK-Ebene, darüber die ROS-2-Orchestrierung in Python, verbunden über DDS-Zustandsnachrichten mit 10–50 Hz.

Die Regelschleife bleibt in C++ auf dem Roboter. Die High-Level-Ebene läuft in ROS-2-Nodes, entweder auf dem Applikationsprozessor des Roboters (Jetson Orin AGX) oder, bei schwereren Aufgaben, auf dem externen Inferenzserver (siehe I01). Die beiden Ebenen sprechen mit 10–50 Hz über DDS miteinander. Sie teilen sich keinen Prozess.

Diese Trennung ist nicht optional. Ein ROS-2-Node in Python kann keine 1-kHz-Gelenkschleife schließen — allein der Garbage Collector macht das unmöglich. Es dennoch zu versuchen, ist der häufigste Fehler im ersten Jahr humanoider Robotik. Das Hersteller-SDK existiert genau deshalb, damit Sie es nicht müssen.

Wann Sie einen Simulator brauchen (und wann nicht)

Für vier Arten von Arbeit ist ein Simulator Pflicht:

• Reinforcement Learning. Sie können eine Lokomotions-Policy nicht von Grund auf am realen Roboter trainieren. Der Roboter ginge kaputt, der Trainer würde kündigen, die Kosten wären absurd. RL findet in der Simulation statt — Millionen Episoden, Tausende Umgebungen parallel.
• Datengenerierung im großen Stil. Synthetische Daten für VLM-Finetuning, Szenenverständnis, Greifvorgänge. Die Teams an der Spitze (R09) erzeugen über Nacht Hunderttausende annotierte Szenen.
• Headless-CI. Sie wollen, dass jeder Git-Push prüft, ob der Roboter noch läuft. Auf echter Hardware ist das unpraktikabel. Ein nächtlicher Simulationslauf, der Lokomotions- und Wahrnehmungs-Stack durchexerziert, ist es nicht.
• Umgebungsplanung. Ein Lager, eine Fertigungszelle, ein Labor auslegen — und wissen, ob der Roboter darin navigieren kann, bevor Sie es bauen.

Keinen Simulator brauchen Sie für:

• Frühes Prototyping. Wenn Sie eine „Roboter winkt"-Demo schreiben, ist ein Simulator reiner Overhead. Nehmen Sie den echten Roboter.
• Einfache Manipulation. Eine Kiste aufheben, eine Schublade öffnen. Die Sim-to-Real-Lücke ist bei diesen Aufgaben oft größer als die Zeit, die Sie am echten Roboter gebraucht hätten.
• Teleoperations-Entwicklung. Der ganze Sinn der Teleoperation ist der Mensch in der Schleife. Die Simulation hilft dabei nicht.
• Einmalige Verhaltensweisen. Alles, was Sie zweimal ausführen und dann wegwerfen.

Der Fehler, den Teams machen, ist, den Simulator als Standard zu behandeln. Das ist er nicht. Er ist ein Werkzeug für die vier genannten Fälle, plus dem offensichtlichen Sicherheitsargument „ich will den echten Roboter nicht zu Schrott fahren".

Das Simulator-Feld 2026

Für Laufroboter zählen 2026 vier Simulatoren. Sie sind nicht gleichwertig, und die Wahl ist eine Frage der Haltung.

Die Zahlen in der Spalte der parallelen Umgebungen sind Praxiswerte, keine theoretischen. Sie hängen von der Modellkomplexität ab. Ein Franka-Arm läuft in höherer Parallelität als ein Humanoid mit 41 Freiheitsgraden und geschickten Händen.

Isaac Sim und Isaac Lab — NVIDIAs Wette

Isaac Sim ist der fotorealistische, GPU-beschleunigte Simulator auf Basis des Omniverse-Stacks. Isaac Lab ist das Roboter-Lernframework, das darauf aufsetzt. Zusammen sind sie NVIDIAs Antwort auf jede Frage der Robotiksimulation.

Was er gut kann:

• Fotorealistisches Rendering. Raytracing-Beleuchtung, physikalisch korrekte Materialien, realistische Kameramodelle. Wenn Ihr Wahrnehmungs-Stack lernen muss, wie die Welt tatsächlich aussieht, ist das der einzige Simulator, der das in dieser Größenordnung liefert.
• GPU-beschleunigte Physik. Parallele Umgebungen liegen im GPU-Speicher. Eine einzelne RTX 5090 betreibt Tausende humanoider Instanzen mit Hunderten Physikschritten pro Sekunde.
• Isaac Lab. Ein aufgeräumtes RL-Framework mit integrierter Unterstützung für RSL RL, RL-Games, SKRL und Stable Baselines3. Zu den mehr als 16 vorgefertigten Robotermodellen zählen G1, H1, Spot, ANYmal, Franka und eine wachsende Zahl von Neuzugängen.
• GR00T-Integration. NVIDIAs Foundation-Model-Stack für Humanoide ist hier zu Hause. Wenn Sie eine Vision-Language-Action-Policy trainieren und plattformübergreifend ausrollen wollen, führt der Weg hierüber.

Was er schlecht kann:

• Der Omniverse-Aufbau schmerzt. Die Omniverse-Laufzeitumgebung ist eigenwillig, schwergewichtig und mit einer Standard-Ubuntu-Installation nicht eben freundlich. Rechnen Sie mit einem Tag Ringen um Launcher, Nucleus-Server und Asset-Cache, bevor Ihre erste Simulation läuft.
• GPU-gebunden. Isaac Sim läuft nicht auf einer CPU. Und auf einer einzelnen 4090 läuft es nicht gut. Das Referenz-Setup ist mindestens eine 5090, besser eine Pro 6000 Blackwell, dazu ein EPYC-Host, der die Daten nachliefert.
• Eigenwillig. Assets liegen in USD vor. Die Physik ist PhysX. Das Rendering ist RTX. Wer eine andere Physik-Engine will, ist im falschen Simulator.

Was das für die Rechenleistung heißt. Ein Kentino AI Server mit 4× RTX 5090 bewältigt Humanoid-Training in Isaac Lab komfortabel — 4,000–8,000 parallele Umgebungen, voller Fotorealismus mit 30–60 FPS Render-Leistung, Konvergenz einer Lokomotions-Policy in 6–24 Stunden. Mit 8× 5090 skalieren Sie breiter oder fahren mehrere Experimente parallel. Die Pro 6000 Blackwell ist die richtige Wahl, wenn der Speicher der limitierende Faktor ist (große Batch-Größen, umfangreichere Humanoid-Asset-Bibliotheken).

MuJoCo und MJX — die Antwort mit Physik zuerst

MuJoCo ist der Physiksimulator von DeepMind. MJX ist die XLA-/JAX-Neuimplementierung, die MuJoCo mit vollständigem Batching auf der GPU ausführt. MJWarp ist ein neueres Gemeinschaftsprojekt von NVIDIA und Google, das MuJoCo in Warp schreibt und bei kontaktreichen Szenen besser skaliert.

Was er gut kann:

• Tempo. Reine kontaktreiche Starrkörperphysik, von Grund auf für die GPU geschrieben. Auf einer einzelnen RTX 5090 fährt MJX Tausende humanoider Umgebungen mit Physikschritten pro Sekunde, die Isaac Sim bei gleicher Szenenkomplexität nicht erreicht.
• Determinismus. Gleicher Seed, gleiche Trajektorie. Reproduzierbares RL ist ein Feature.
• Rückhalt durch DeepMind. Jede größere Robotik-Veröffentlichung von DeepMind der letzten fünf Jahre nutzt MuJoCo. Die Modellbibliotheken (MuJoCo Menagerie) enthalten G1, H1, Spot, ANYmal, den Franka-Arm und die Shadow Hand.
• Einfacher. Kein Omniverse, kein USD, kein Nucleus. Pip install, los geht's.

Was er schlecht kann:

• Visuelles Rendering. MuJoCos Renderer stammt aus der OpenGL-Ära. Für die Visualisierung reicht es, für fotorealistische Datengenerierung ist es unbrauchbar.
• Asset-Ökosystem. Kleiner als bei Isaac. URDF-Importe funktionieren, sind aber weniger ausgefeilt.
• Sensormodelle. Kamera-, Tiefen- und LiDAR-Modelle sind rudimentär. Wenn Ihre Policy von realistischem Sensorrauschen abhängt, bauen Sie diese Modelle selbst.

Was das für die Rechenleistung heißt. Eine einzelne RTX 5090 fährt je nach Kontaktkomplexität 4,000–16,000 parallele humanoide MJX-Umgebungen. Ein Kentino AI Server mit 4× 5090 schafft über 50,000 humanoide Umgebungen parallel für Lokomotions-RL. Diese Rechnung ist der Grund, warum DeepMind und die meisten akademischen Labore für die innere Schleife des Policy-Trainings auf MuJoCo setzen.

Gazebo Harmonic — der ROS-2-Eingeborene

Gazebo ist der quelloffene Simulator, der seit zwei Jahrzehnten der Standard für ROS ist. Gazebo Harmonic ist die aktuelle LTS und passt sauber zu ROS 2 Humble und Jazzy.

Was er gut kann:

• ROS-2-Integration. Erstklassig. Dank der ros_gz-Bridge laufen Ihre ROS-2-Nodes ohne Änderung in der Simulation.
• Offen und kostenlos. Keine Lizenz, kein Omniverse, keine NVIDIA-Abhängigkeit. Läuft auf CPU, auf AMD-GPUs, auf allem.
• Richtig für Integrationstests. Wenn Ihr Ziel lautet „prüfen, ob Navigations-Stack und Planer nach einem Refactoring noch funktionieren", ist Gazebo die richtige Wahl.

Was er schlecht kann:

• Langsam. Single-Threaded-Physik, standardmäßig Software-Rendering. Parallele Umgebungen bedeuten mehrere Gazebo-Prozesse. RL-Policies trainiert man nicht in Gazebo, man macht dort den Rauchtest.
• Nicht GPU-freundlich. Kein GPU-Batching. Rendering-Beschleunigung hilft, ändert aber nichts an der grundsätzlichen Skalierung.
• Größere Sim-to-Real-Lücke. Das Kontaktmodell ist weniger streng als bei MuJoCo, die Sensormodelle sind weniger realistisch als bei Isaac.

Was das für die Rechenleistung heißt. Gazebo läuft auf allem, was Sie haben. Der Kentino AI Server ist dafür überdimensioniert. Ein Laptop genügt. Der Haken: Bei jeder nicht-trivialen RL-Aufgabe sind Sie Gazebo binnen Tagen entwachsen.

Genesis — der akademische Hochdurchsatz-Kandidat

Genesis ist der von mehreren Institutionen getragene Simulator, der Ende 2024 mit kühnen Leistungsversprechen erschien und die meisten davon inzwischen eingelöst hat. CMU, Stanford, MIT CSAIL, NVIDIA und Tsinghua haben beigetragen.

Was er gut kann:

• Durchsatz. Genesis erreicht auf einer einzelnen RTX 4090 über 40 Millionen FPS bei einer inversen Kinematik für den Franka-Arm. Bei Humanoiden liegt der Wert niedriger, aber immer noch im Millionenbereich. Die Architektur ist von Anfang an auf massiv parallele Simulation ausgelegt.
• Multiphysik. Starrkörper, Fluide, weiche Körper, Granulate, MPM. Wenn Ihre Aufgabe über starren Kontakt hinausgeht (Manipulation verformbarer Objekte, Gießen von Flüssigkeiten, granulare Interaktion), ist Genesis der einzige Simulator dieser Liste, der das nativ beherrscht.
• Generative Szenenwerkzeuge. Genesis bringt promptgesteuerte Szenengenerierung mit. Sie beschreiben eine Umgebung als Text und erhalten eine Szene.

Was er schlecht kann:

• Jüngeres Ökosystem. Weniger vorgefertigte Modelle, weniger Tutorials, kleinere Community als bei MuJoCo oder Isaac.
• Weniger erprobt bei Sim-to-Real. Die Physik ist schnell; ob sie sich auf Hardware ebenso gut überträgt wie MuJoCo, klärt die Community gerade erst.
• Lücken in der Dokumentation. Typisch für sich rasch entwickelnde Forschungsprojekte.

Wo er 2026 hingehört. Genesis ist die richtige Wahl für akademisches RL, wenn Sie maximalen Umgebungsdurchsatz wollen und bereit sind, mehr eigenen Glue-Code zu schreiben. Für eine produktive Sim-to-Real-Pipeline ist MuJoCo oder Isaac heute die sicherere Wahl. Behalten Sie die Entwicklung im Auge.

Sim-to-Real in der Praxis, Ausgabe 2026

Der praktische Stand von Sim-to-Real, Mai 2026:

• Domain Randomization ist Pflicht. Sie können nicht auf einem einzigen Satz Physikparameter trainieren und einen Transfer erwarten. Masse, Reibung, Motorverzögerungen, Sensorrauschen, Latenz — all das wird im Training über einen Bereich hinweg randomisiert.
• Die Aktionsverzögerung wiegt schwerer, als man zugibt. Die Aktoren eines echten Roboters haben 5–25 ms Verzögerung vom Befehl bis zum Moment. Eine Simulation ohne diese Verzögerung erzeugt Policies, die auf der Hardware schwingen. Bauen Sie die Verzögerung vom ersten Tag an in die Simulation ein.
• Sensorrauschen muss eingespeist werden. IMU-Drift, Bildrauschen, Aussetzer des Tiefensensors. Die Arbeiten von 2026, die funktionieren, haben all das im Training.
• Training über mehrere Simulatoren ist die Speerspitze. PolySim und ähnliche Frameworks trainieren gleichzeitig über MuJoCo + Isaac + teils Gazebo. Die ersten Ergebnisse sind gut. Der Rechenaufwand liegt beim 2–3-Fachen eines Einzelsimulator-Trainings.
• Humanoide Bewegung unter Last bleibt schwierig. Eine Nutzlast tragen, einen Stoß abfangen, während man etwas trägt — das verschlechtert sich auf den Plattformen aus R01 von der Simulation zur Realität noch immer um 50–80 %.

Planen Sie damit, dass zwei Drittel Ihrer Leistung in der realen Welt aus der Simulation kommen. Und damit, dass das letzte Drittel aus Hardware-Feintuning, Systemidentifikation und hartnäckigem Debugging besteht.

Konkretes Rezept: G1 + ROS 2 Humble + Isaac Lab auf einem Kentino AI Server

Hardware:
  - Unitree G1 EDU (Jetson Orin AGX, 23–43 DOF)
  - Kentino AI 256 Turin Dual / 4× RTX 5090 / 1× RTX Pro 6000 Blackwell
    (die Pro 6000 für die Simulation, die 5090er für gebatchtes Policy-Training)
  - Wi-Fi-6E-Accesspoint, Sichtverbindung zum Arbeitsbereich
  - 10-GbE-Switch, kabelgebundene Verbindung vom Kentino AI zum Accesspoint

Software auf dem Kentino AI Server:
  - Ubuntu 22.04, CUDA 13, Docker
  - Isaac Sim 5.x + Isaac Lab (Omniverse-Runtime, Nucleus lokal)
  - ROS 2 Humble (oder Jazzy, bei einem Neustart heute)
  - PyTorch 2.x, JAX, RSL RL
  - vLLM, das ein VLM für die High-Level-Wahrnehmung bereitstellt (siehe I02)
  - MuJoCo + MJX als zweite Simulation, zur simulationsübergreifenden Validierung

Software auf dem G1:
  - Unitree SDK2 (C++-Gelenkregelschleife)
  - unitree_ros2 (Humble) auf dem Jetson
  - Eigene ROS-2-Nodes: command_router, perception_relay
  - gRPC-Client zum vLLM auf dem Kentino AI Server

Arbeitsablauf:
  1. Eine Lokomotions- oder Ganzkörper-Policy in Isaac Lab auf der
     Pro 6000 trainieren (4,000+ parallele G1-Instanzen, RSL RL).
  2. Die Policy in MJX validieren (4× 5090 gebatcht) mit anderen
     Seeds für die Domain Randomization.
  3. Die Policy per TorchScript auf den Jetson des G1 ausrollen, verpackt
     in einen ROS-2-Node, den die Regelschleife des Unitree SDK2 aufruft.
  4. High-Level-Befehle aus ROS 2 fließen aus dem Task-Graph des Labors
     über den command_router in die Policy.
  5. Schwere Wahrnehmung (VLM) läuft auf dem Kentino AI Server, erreichbar über
     Wi-Fi 6E + gRPC.

Die gesamte Aufbauzeit beträgt für ein Team mit ROS-2-Erfahrung zwei bis drei Wochen. Für ein Team, das ROS 2 von Grund auf lernt, sind es zwei bis drei Monate. Planen Sie entsprechend. Die Rechenseite des Kentino AI Servers ist der einfachere Teil.

Die ehrliche Einschätzung

Drei Meinungen, unverblümt:

1. ROS 2 ist die richtige Abstraktionsebene. Native SDKs sind notwendig, aber nicht hinreichend. Bauen Sie auf dem ROS-2-Wrapper auf und behandeln Sie das Hersteller-SDK als Dienst, den der Wrapper nutzt. Der proprietäre Weg bringt Ihnen nichts und kostet Sie das gesamte übrige Ökosystem.
2. Isaac Sim ist die Zukunft, aber die Gegenwart heißt für die meisten Teams MuJoCo + ROS 2. Wenn Ihre Arbeit RL für Lokomotion und geschickte Manipulation ist, ist MuJoCo / MJX die günstigere, schnellere und einfacher auszurollende Wahl. Wenn Ihre Arbeit fotorealistische Wahrnehmung, Datengenerierung im großen Stil oder VLA-artiges Finetuning von Foundation Models ist, führt an Isaac kein Weg vorbei. Die meisten Labore brauchen beides, und der Kentino AI Server hat die Reserven, um beides zu fahren.
3. Die führenden Labore nutzen alle vier. Isaac für das Rendering und die Foundation-Model-Pipeline. MuJoCo für die innere RL-Schleife. Gazebo für die ROS-2-Integrationstests. Genesis für die Multiphysik-Arbeit. So zu tun, als bräuchten Sie nur einen, ist der Grund, warum Teams nach einem Jahr ihren Stack neu schreiben.

---

Dieser Beitrag ist Teil des Kentino Wiki, einer Referenzreihe zu KI-Rechenleistung, Robotik und den Systemen, die beides verbinden. Anmerkungen und Korrekturen gern an info@kentino.com.