Roboter-Lern-Tech-Startup-Stack: Schlüsselentscheidungen für 2025
Technologieentscheidungen für Robotik-Startups <unk> ROS2 vs. benutzerdefiniertes Middleware, Simulationswahl, Cloud vs Edge-Entscheidung und Datenplattformstrategie.
[← Blog]
Die vier Infrastrukturentscheidungen, die Ihre Architektur für die nächsten drei Jahre einschränken werden -- und wie Sie sie in jeder Finanzierungsphase richtig machen.
Entscheidung 1: ROS2 gegen benutzerdefiniertes Middleware
Das ist die Frage, die jeder Robotikstartup debattiert und die meisten machen sich durch Überingenieurung Irrtum. ROS2 gibt Ihnen einen schneller laufenden Roboter, gibt Ihnen Zugang zu einem großen Ökosystem von Fahrern und Werkzeugen und erleichtert die Einstellung -- die meisten Robotikingenieure kennen ROS2. Die Pub/Sub-Architektur behandelt die Komplexität von Multi-Node-Systemen, und Pakete wie MoveIt2, Nav2 und ros2_control behandeln Probleme, die Monate dauern würden, um von Grund auf zu implementieren.
Custom-Middleware bietet zwei echte Vorteile: Latenz unter 5ms (DDS-Overhead vonROS2 macht dies fast unmöglich) und Freiheit von Lizenzproblemen, wenn Ihr kommerzielles Bereitstellungsmodell die Umverteilung einer modifizierten middleware-Schicht beinhaltet.
Die praktische Regel: ROS2 verwenden, es sei denn, Sie sind in der Serie B oder später mit einem Versandprodukt, das echte Latenzbeschränkungen gezeigt hat. Frühe Optimierung von Middleware ist einer der teuersten Fehler in Robotik-Startups - die Chancenkosten von 6 Monaten, um DDS wieder aufzubauen, sind im frühen Stadium enorm. Wenn Latenz später zu einer wirklichen Einschränkung wird, können Sie die Transport-Schicht immer ersetzen und gleichzeitig die ROS2-Schnittstellen behalten.
ROS2 DDS-Anbieterwahl
Wenn Sie ROS2 wählen, ist der DDS-Anbieter wichtiger als die meisten Teams erkennen. Das Standard CycloneDDS ist eine solide Wahl für die meisten Anwendungen. FastDDS (das vorherige Standard) hat bessere Entdeckung in großen Multi-Maschine-Setups, aber höhere Speicherüberschüsse. Für Echtzeitsteuerungsschleifen beseitigt CycloneDDS mit Iceoryx-Geteilterminetransport (Null-Copy) die Serialisierungshöhe, die Standard-DDS für die inner-Schleife-Steuerung zu langsam macht.
Ein gemeinsames Muster bei RCSV-gestützten Startups: CycloneDDS für alle nicht-Echtzeit-Knoten (Perception, Planung, Logging) ausführen und einen leichten benutzerdefinierten Transport (raw UDP oder Shared Memory) für die 500Hz+ interne Steuerung zwischen dem Policy-Inferenz-Knoten und dem Motorcontroller verwenden. Dieser Hybridansatz erhält 95% des ROS2-Ökosystems mit den Latenzmerkmalen von benutzerdefiniertem Middleware, wo es zählt.
# Example: ROS2 + zero-copy shared memory via iceoryx
# In your ros2 workspace, set the middleware:
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp
# cyclonedds.xml -- enable iceoryx shared memory transport
# <CycloneDDS>
# <Domain>
# <SharedMemory>
# <Enable>true</Enable>
# <LogLevel>warning</LogLevel>
# </SharedMemory>
# </Domain>
# </CycloneDDS>
export CYCLONEDDS_URI=file://$(pwd)/cyclonedds.xml
Entscheidung 2: Simulationsplattform
Die Wahl der Simulation prägt Ihre Trainingsschleife für Jahre.
| Simulator | Parallel Envs | Contact Physics | License | Best For | GPU Required |
|---|---|---|---|---|---|
| Isaac Lab | 4,096+ on A100 | Adequate | MIT (BSD-3 for Sim) | GPU-parallel RL, locomotion | Yes (RTX 3090+) |
| MuJoCo | ~1,000 (MJX on GPU) | Excellent | Apache 2.0 | Contact-rich manipulation, dexterous hands | No (CPU OK; GPU for MJX) |
| Genesis | 10,000+ on A100 | Good (MPM for soft body) | Apache 2.0 | Soft body, deformables, fluids | Yes |
| Gazebo (Ignition) | 1-10 (CPU only) | Adequate | Apache 2.0 | ROS2 integration testing, sensor sim | No |
NVIDIA Isaac Lab: Die beste Wahl, wenn GPU-beschleunigtes RL-Training Ihr Hauptverwendungsfall ist. 4.096+ parallele Umgebungen auf einem einzigen A100, enge Isaac Sim-Integration, MIT-Lizenz, wachsende Modell Zoo einschließlich Unitree G1 und Franka. Schwach in Bezug auf die Kontaktgenauigkeit - gut für die Bewegung und Pick-Place, Schwierigkeiten für die Präzisionsmontage. Das PhysX-Backend ist schnell, verwendet jedoch einen penalty-basierten Kontakt, der die Penetration bei hohen Zeitstufen ermöglicht.
MuJoCo: Beste Kontaktphysik in jedem Simulator für allgemeine Zwecke. Einschränkungsbasierte Dynamik mit stabilem Kontakthandhabung bei hoher Konformität. Wählen Sie dies für geschickte Handforschung, kontaktreiche Manipulation oder jede Aufgabe, bei der Kontaktgenauigkeit mehr zählt als Parallelisierung. Jetzt kostenlos unter Apache 2.0 seit der Übernahme von Google. MuJoCo XLA (MJX) bringt GPU-Beschleunigung über JAX mit sich, um etwa 1.000 parallele Umgebungen zu erreichen - nicht so schnell wie Isaac Lab, aber ausreichend für die meisten Manipulationen RL.
Die neue Teilnehmerin ist die erste, die schnell für Aufgaben mit verformbaren Objekten, Flüssigkeiten und weichen Körpern übernommen wird. Die Genesis verwendet die Material Point Method (MPM) für die Körperphysik, die sowohl für die Simulation von Stoff, Lebensmitteln als auch menschlichen Geweben überlegen ist. Durchsatz bei starren Körper-Aufgaben rivalisiert Isaac Lab.
Gazebo (Ignition): Wählen Sie nur, wenn die tiefe ROS2-Integration eine harte Voraussetzung ist - Gazebo ist der offizielle ROS2-Simulator und verfügt über die engste Werkzeugkettenintegration. Die Physik ist schwächer als die GPU-beschleunigten Alternativen. Akzeptabel für Navigation, Sensorsimulation und Integrationsprüfung. Nicht lebensfähig für RL-Training aufgrund der CPU-nur Ausführung.
Politikarchitektur: ACT vs. Diffusionspolitik vs. OpenVLA
Ihre Wahl der politischen Architektur ist eng mit Ihrer Simulations- und Datenstrategie verbunden.
| Architecture | Paradigm | Data Needed | Inference Speed | Best For |
|---|---|---|---|---|
| ACT | IL (CVAE + Transformer) | 50-200 demos/task | ~5ms (fast) | Precise bimanual manipulation |
| Diffusion Policy | IL (DDPM denoising) | 100-500 demos/task | ~100-200ms (slow) | Multi-modal tasks, diverse strategies |
| OpenVLA / RT-2 | VLA (vision-language-action) | Fine-tune: 20-100 demos + pre-trained backbone | ~200-500ms (very slow) | Language-conditioned, multi-task |
| PPO/SAC (RL) | RL (reward-driven) | 0 demos (sim only) | ~1-5ms (very fast) | Locomotion, tasks with clear rewards |
Praktische Anleitung: Beginnen Sie mit ACT, wenn Sie Teleoperationsdaten sammeln und eine schnelle Iteration benötigen. ACT trainiert in Stunden auf einer einzigen GPU und die Ableitung ist schnell genug für die Echtzeitsteuerung. Wechseln Sie zu Diffusion Policy, wenn Sie feststellen, dass Ihre Aufgabe mehrere gültige Strategien hat (z. B. Ansatz von links oder rechts) - ACT's unimodal CVAE kämpft mit multimodalen Demonstrationen, während Diffusion Policy sie natürlich behandelt. Verwenden Sie OpenVLA/RT-2 nur, wenn Sie Sprachkonditionierung (Führung von natürlichen Sprachanweisungen) benötigen oder sich von einem vorgebildeten Grundmodell aus einstellen. Die Ableitgeschwindigkeit von VLAs (200-500 ms) beschränkt sie auf Aufgaben, bei denen die Reaktionszeit nicht kritisch ist.
Entscheidung 3: Wolke gegen Edge-Inferenz
Die Inferenz-Latenz bestimmt, wo Ihr Modell läuft. Die Schwelle beträgt etwa 150ms Rundfahrt: Unterhalb davon ist die Cloud-Inferenz aus einem co-located-Datencenter für die meisten Anwendungen praktikabel. Über 150ms führt zu spürbarem Verzögern bei der Teleoperation und verursacht Instabilität in Closed-Loop-Manipulation-Controllern.
Edge Computing: aktuelle Hardware Landschaft
| Device | TOPS | Price | ACT Inference | Diffusion Policy | OpenVLA 7B |
|---|---|---|---|---|---|
| Jetson Orin Nano (8GB) | 40 | $249 | ~15ms | ~300ms | Not feasible |
| Jetson AGX Orin (64GB) | 275 | $1,999 | ~5ms | ~120ms | ~800ms (quantized) |
| Jetson Thor (expected 2025-26) | ~800 | ~$2,500 est. | ~2ms | ~40ms | ~200ms (feasible) |
Cloud-Förderung ist sinnvoll, wenn: Roboter-Konnektivität ist zuverlässig (Labor oder Fabrik mit Faser), Latenz > 150ms ist für die Anwendung akzeptabel, und Modellgröße übersteigt, was Edge-Hardware dienen kann. Ein Hybrid-Ansatz funktioniert gut - schnelle Low-Latenz-reaktive Controller auf dem Gerät, entladen langsamer Planung und Wahrnehmung in die Cloud.
Cloud-Schulung: Kosten-Benchmarks
Die Kosten für die Ausbildung variieren stark je nach Politikarchitektur und Datensatz.
- ** ACT (einfach aufgetragen, 200 Demo):** ~8 Stunden auf 1x A100 (40GB). Kosten: ~$16 auf Lambda Cloud ($2/Std). ~$24 auf AWS p4d-Instanzen.
- ** Diffusion Policy (einfach aufgetragen, 500 Demo):** ~24 Stunden auf 1x A100. Kosten: ~$48 auf Lambda. Bildbeobachtungen mit 3 Kameras ungefähr dreifache Trainingszeit gegenüber Low-Dimen Beobachtungen.
- OpenVLA Feintuning (7B, 100 Demo): ~ 12 Stunden auf 4x A100 (LoRA). Kosten: ~ 96 $ auf Lambda. Voll feintuning erfordert 8x A100 und ~ 200 $+.
- PPO-Lokomotion (Isaac Lab, 4096 std.): ~4 Stunden auf 1x RTX 4090. Kosten: ~4$ auf vast.ai.
Entscheidung 4: Strategie für die Datenplattform
Die Entscheidung, Dateninfrastruktur zu bauen oder zu kaufen, ist einfacher, als es scheint. Bauen Sie Ihre eigene Datenplattform nur, wenn Sie einen engagierten ML-Infrastrukturingenieur haben, dessen Hauptbeschäftigung die Datenverarbeitung ist - nicht ein Forscher, der auch die Werkzeuge pflegt, ein engagierter Infringenieur. Andernfalls wird die Wartungslast zu einer erheblichen laufenden Steuer für Ihre teuersten Menschen.
Was eine Datenplattform tun muss
Die Kernfunktionen, die Sie benötigen: Episodenspeicherung mit Versionsverarbeitung, Metadatenindexung für schnelle Abrufung, Visualisierung für QA, Datensatzspaltung und Export in Schulungsformate (HDF5/Zarr/RLDS) und Zugriffskontrolle für Multi-Operator-Umgebungen.
Vergleiche mit den Tools für das Datensatzmanagement
| Tool | Type | Robot-Specific | Collection Tools | Training Integration |
|---|---|---|---|---|
| RCSV Platform | Managed service | Yes (teleop, annotation, QA) | Full (hardware + software) | HDF5/RLDS/LeRobot export |
| HuggingFace LeRobot | Open-source lib | Yes (robot datasets) | Recording scripts | ACT, DP, TDMPC built-in |
| Weights & Biases | Managed service | No (general ML) | Experiment tracking only | Any framework |
| DVC + MinIO | Open-source stack | No (general ML) | Version control only | Any framework |
Das Prinzip, das jede Stackentscheidung leiten sollte: Infrastruktur kaufen, Differenzierung bauen. Deine Wettbewerbsvorteile sind deine Roboterhardware, deine Aufgabenkompetenz und deine Richtlinienarchitektur - nicht dein Episoden-Speichersystem. Verbring entsprechend Zeit im Ingenieurwesen.
Die [RCSV-Plattform]
Empfohlene Stufe nach Stufe
| Stage | Middleware | Sim | Policy | Inference | Data Platform |
|---|---|---|---|---|---|
| Pre-seed / Seed | ROS2 Humble | MuJoCo or Isaac Lab | ACT (fast iteration) | Edge (Orin Nano) | RCSV or LeRobot |
| Series A | ROS2 + custom control | Isaac Lab + MuJoCo | Diffusion Policy or VLA fine-tune | Hybrid edge+cloud | RCSV or build if infra hire |
| Series B+ | Custom if proven need | Custom + one of above | Custom architecture | Custom serving (TRT) | Build if 2+ infra eng |
Verwandte Lesungen
- [Ein Robotics Startup im Jahr 2026 bauen]
- ACT-Politik erklärt -- tief in den beliebtesten IL-Algorithmus eintauchen
- Belohnungs-Shaping for Manipulation RL -- wenn Sie den RL-Pfad wählen
- RCSV Datenplattform -- verwaltete Dateninfrastruktur
- RCSV Glossar -- Definitionen für in diesem Artikel verwendete Begriffe
Benötigen Sie eine Dateninfrastruktur ohne den Baukosten?
Die Plattform von RCSV verwaltet Episodenspeicherung, Anmerkung, Visualisierung und Ausbildungspipelinexport - so dass sich Ihr Team auf den Roboter konzentrieren kann.
[Schauen Sie die Plattform] [