Robotiksimulation für Forschungslabore: Vom Konzept zur hardware

Wichtigste Erkenntnisse

• Eine Robotersimulation erweist sich bei hardware als nützlich, wenn Timing, I/O und die Ausführung des Controllers bereits vor der Auswahl des Tools festgelegt werden.
• Die Simulation von Sensoren und eingebetteten Systemen ist dann von größter Bedeutung, wenn dadurch Fehler reproduziert werden, die die Regelausgabe, die Konfidenz des Schätzers und das Timing der Firmware beeinflussen.
• Der Übergang von der Konzeptphase zur Laborprüfung verläuft reibungsloser, wenn der Umfang der HIL-Tests schrittweise erweitert wird und für jeden Schritt feste Erfolgskriterien festgelegt sind.

Forschungslabore sollten die Robotersimulation als Validierungssystem betrachten, lange bevor eine Steuerung in hardware implementiert wird.

Diese Verschiebung ist von Bedeutung, da das größte Risiko selten allein in der Physik liegt. Es liegt vielmehr im Timing, in der Sensorverzögerung, im Busverkehr und in Firmware-Annahmen, die in einem Desktop-Modell zunächst einwandfrei erscheinen. Der weltweite Bestand an Industrierobotern erreichte im Jahr 2023 4.281.585 Einheiten, was zeigt, wie wichtig validierte software für Labore und Produktionsteams ist. Wenn Ihre Robotersimulation nicht im geschlossenen Regelkreis mit deterministischem Timing laufen kann, liefert sie Ihnen nicht genügend Informationen, wenn Sie von der Konzeptphase zu Tests übergehen.

Forschungslabore benötigen vor der Auswahl der Werkzeuge einen Validierungsprozess

Ein sinnvoller Plan für eine Robotik-Simulation beginnt mit den hardware , die Sie klären müssen, und arbeitet sich dann rückwärts zu Modellen und Werkzeugen vor. Forschungslabore verlieren Zeit, wenn sie einen Simulator aufgrund der grafischen Darstellung oder der Größe der Nutzer-Community auswählen, bevor sie Latenzgrenzen, I/O und Steuerungsziele definiert haben. Ihr Validierungspfad sollte festgelegt sein, bevor Ihr software wächst. Dieser Pfad wird jeden späteren Test prägen.

Ein Team für mobile Roboter liefert ein einfaches Beispiel. In der frühen Konzeptphase sind möglicherweise nur Kinematik, Kartenwiedergabe und die Feinabstimmung des Planers erforderlich. Hardware stellen sich jedoch schwierigere Fragen: Kann der Radregler die Geschwindigkeit trotz Encoder-Rauschen aufrechterhalten, kann sich der Schätzer von Paketverzögerungen erholen, und verpasst der Prozessor Fristen, wenn die Wahrnehmungslast steigt? Diese Fragen führen Sie schon lange vor dem Vergleich verschiedener Tools zur Sensorsimulation, zur Simulation eingebetteter Systeme und zu Timing-Prüfungen im geschlossenen Regelkreis.

Dieser Schritt ist wichtig, da jede Validierungsphase neue Einschränkungen mit sich bringt, deren nachträgliche Anpassung mit hohem Aufwand verbunden ist. Schnittstellenvereinbarungen, Abtastraten und Fehlerfälle sollten frühzeitig festgelegt werden, solange die Modelle noch leicht zu bearbeiten sind. Labore, die diesen Schritt überspringen, müssen später häufig die Anlagenmodelle und Regler-Wrapper neu erstellen. Die bessere Vorgehensweise ist ganz einfach: Definieren Sie zunächst, was auf hardware nachgewiesen werden muss, und gestalten Sie die Simulation dann entsprechend diesem Nachweis.

Die Ausführung im geschlossenen Regelkreis bestimmt den Simulationswert für hardware

Unter „Closed-Loop-Ausführung“ versteht man, dass Regler, Anlagenmodell und I/O mit festem Zeitablauf und gemessener Latenz ablaufen. Genau darin liegt der Wert der Simulation bei hardware . Ein Modell, das stabil erscheint, während es zwischen den Komponenten zu Zeitverschiebungen kommt, verschleiert genau die Fehler, die Sie eigentlich aufdecken müssen. In dieser Phase ist Determinismus wichtiger als die Qualität der Darstellung.

Ein Zweirad-System verdeutlicht dies. Die Motorstromschleife läuft möglicherweise mit 1 kHz, der Zustandsschätzer mit 100 Hz und die Lidar-Pipeline mit 10 Hz. Wenn der Anlagenlöser unter Last ins Stocken gerät, erscheint der Regler auf einer Desktop-Kurve zwar weiterhin einwandfrei, doch dieselbe Logik kann in Schwingungen geraten, wenn physikalische Antriebe feste Fristen erwarten. Sie benötigen eine Konfiguration, die versäumte Schritte, Jitter und Scheduler-Überschreitungen sichtbar macht, anstatt sie zu glätten.

Deshalb beginnt die Echtzeit-Robotiksimulation zur hardware mit der Einhaltung von Schrittgrößen, der Aufgabenteilung und der Zuordnung von Zeitstempeln. Modelle mit mehreren Raten sind zwar in Ordnung, doch jede Rate muss bewusst gewählt und wiederholbar sein. Sie validieren das Regelverhalten, und Bewegungsdiagramme allein reichen nicht aus. Wenn die Zeitangaben korrekt sind, lassen sich Ihre Testergebnisse problemlos von der Modellprüfung auf die Laborarbeit übertragen.

„Unter ‚Closed-Loop-Ausführung‘ versteht man, dass der Regler, das Anlagenmodell und I/O mit festem Zeitabstand und bei bekannter Latenz ablaufen.“

Die Sensorsimulation muss das Timing-Rauschen nachbilden, das Ihr Roboter wahrnehmen wird

Die Sensorsimulation muss hinsichtlich Timing, Rauschen, Quantisierung und Datenausfällen so realitätsnah wie möglich sein, um den Steuerungsstack auf die Probe zu stellen. Ein fehlerfreier Sensorstrom sagt nur sehr wenig über hardware aus. Ihr Roboter wird mit versetzten Zeitstempeln, Bewegungsunschärfe, fehlenden Paketen und Abweichungen in den Messwerten konfrontiert sein. Diese Effekte müssen auftreten, bevor hardware angeschlossen hardware .

Ein Feldroboter, der Lidar, einen Inertialsensor und Radodometrie nutzt, verdeutlicht, warum dies von Bedeutung ist. Die Lidar-Daten können mit 10 Hz eintreffen, die Inertialsensor-Daten mit 200 Hz, und jede Quelle kann ihren eigenen Zeitstempel-Fehler mit sich bringen. Der Umsatz mit professionellen Servicerobotern erreichte 205.000 Einheiten im Jahr 2023, und viele dieser Plattformen sind auf Wahrnehmung unter Bewegung und bei wechselnden Lichtverhältnissen angewiesen. Ein Sensormodell, das diese Effekte außer Acht lässt, beeinträchtigt die Lokalisierung und die Pfadverfolgung.

Man braucht nicht für jede Studie eine perfekte optische Darstellung. Wichtig sind vielmehr die Fehlermodi, die den Regelausgang, die Konfidenz des Schätzers oder die Sicherheitslogik beeinflussen. Das bedeutet in der Regel, dass man zunächst mit Timing, Offset, Sättigung und Paketverlust beginnt, bevor man sich mit visuellen Details beschäftigt. Die Sensorsimulation macht sich bezahlt, wenn sie den Regler genauso beeinflusst hardware .

Die Simulation eingebetteter Systeme deckt Schnittstellenfehler bereits vor den Prüfstandstests auf

Die Simulation eingebetteter Systeme deckt Fehler auf, die reine software übersehen, da dabei das Timing der Firmware, die Signalbereiche und I/O anhand der Anlage getestet werden. So erhalten Sie frühzeitig den Nachweis, dass der Controller hardware tatsächlichen hardware bewältigen kann. Die Zeit am Prüfstand wird wertvoller, wenn Schnittstellenfehler bereits bekannt sind. Sie erkennen Fehler in der Verdrahtungslogik und bei den Protokollen früher.

Ein gutes Beispiel hierfür ist eine gemeinsame Steuerung an einem Roboterarm. Die Firmware liest Encoder-Zählwerte aus, filtert die Geschwindigkeit, berechnet das Drehmoment und schreibt Befehle zur Pulsweitenmodulation nach einem festen Zeitplan. Eine Simulation, die sich ausschließlich auf das System bezieht, kann eine stabile Nachführung zeigen, während die tatsächliche Firmware nach einem Reset einen Interrupt überspringt, einen vorzeichenbehafteten Wert beschneidet oder einen Indeximpuls falsch auswertet. Die Simulation eingebetteter Systeme macht diese Fehler sichtbar, noch bevor Motor und Last angeschlossen sind.

Dies ist besonders wichtig, wenn die Steuerung auf einem Mikrocontroller oder einem Feldbus mit strengen zeitlichen Vorgaben läuft. Es ist wünschenswert, dass Prüfsummenfehler, veraltete Pakete und Probleme bei der Startsequenzierung in einer kontrollierten Testumgebung auftreten. Das verkürzt die hardware Zyklen hardware und erhöht die Zuverlässigkeit der Kriterien für „bestanden“ oder „nicht bestanden“. Außerdem sorgt dies für eine bessere Zusammenarbeit zwischen den Teams für Steuerung, Firmware und Labor.

ROS-Workflows stoßen bei der Validierung hardware an ihre Grenzen

Ein ROS-Workflow hilft Teams dabei, Wahrnehmung, Planung und Datenfluss schnell zusammenzuführen, garantiert jedoch kein deterministisches Timing für hardware . Die Nachrichtenübermittlung ist für Iterationen in der Forschung nützlich. Die Ausführung mit festem Schritt und I/O striktes I/O sind separate Anforderungen. Beides ist erforderlich, sobald Steuerungen und physikalische Schnittstellen in den Regelkreis einbezogen werden.

Ein Planungsteam kann protokollierte Sensorthemen erneut abspielen und sich die Ausgabe eines gleichmäßigen Bewegungsablaufs über mehrere Wochen hinweg ansehen. Das Problem tritt auf, wenn derselbe Regler jede Millisekunde Befehle an einen Motorantrieb senden muss, während die Rückmeldung des Zustands über einen separaten Bus eingeht. Nachrichtenwarteschlangen, Taktabweichungen und die Host-Planung können das Timing der Pakete so stark verschieben, dass sich das Verhalten des Reglers ändert. Die software einwandfrei software , bis der Prüfstand feste Fristen hinzufügt.

Das bedeutet nicht, dass der Forschungsstack nutzlos ist. Es bedeutet vielmehr, dass Sie ihn dort einsetzen sollten, wo er am besten passt – nämlich im Bereich der Algorithmenentwicklung, der Orchestrierung und des Datenaustauschs. Die Validierung Hardware erfordert eine strengere Kontrolle über die Ausführung, die Taktung und I/O. Sobald diese Grenze klar definiert ist, wird in Ihrem Robotik-Simulations-Workflow nicht mehr zwischen Forschungszwecken und hardware verwechselt.

Wo sollten HIL Tests für Robotersteuerungen Tests ?

Tests mit der Steuerungsschnittstelle begonnen werden, die das höchste Risiko und die geringste Beobachtbarkeit aufweist. Dabei handelt es sich in der Regel um einen Motorstromkreis, eine Eingabekette eines Zustandsschätzers oder eine Sicherheitsverriegelung. Wenn Sie klein anfangen, erhalten Sie frühzeitig zuverlässige Zeitdaten. Anschließend können Sie die Komplexität des Systems erhöhen, ohne dass der erste Fehler dabei übersehen wird.

Für den ersten Durchlauf eignet sich eine einachsige Testzelle besser als ein vollständiger Roboter. Ein Aktuator, ein Encoder-Weg und eine Steuerplatine vermitteln Ihnen mehr über die Einhaltung der Schrittweite als eine vollständig simulierte Arbeitszelle mit zahlreichen visuellen Details. Sobald dieser Regelkreis stabil läuft, können Sie Sensor-Wiedergabe, Netzwerkverkehr und Überwachungslogik hinzufügen. Jede Ebene sollte eine hardware klären, bevor die nächste hinzukommt.

• Beginnen Sie mit der Schleife, die mit der höchsten Frequenz läuft.
• Das erste HIL-Modell sollte klein genug sein, um jede Verzögerung messen zu können.
• Fügen Sie zunächst einen Sensorpfad hinzu, bevor Sie vollständige Wahrnehmungsstapel hinzufügen.
• Fügen Sie Kategorie nur eine Kategorie ein, damit die Fehler weiterhin übersichtlich bleiben.
• Legen Sie die Kriterien für den Pass-Stopp fest, bevor die erste Sitzung auf der Bank beginnt.

Diese Vorgehensweise verhindert, dass sich HIL zu einem umfangreichen Integrationsprozess mit schwacher Evidenz entwickelt. Sie bauen Schritt für Schritt Vertrauen in die Zeitsteuerung, die Schnittstellen und die Regelungsstabilität auf. Labore, die mit einem kompletten Roboter beginnen, verlieren sich oft in gekoppelten Fehlern. Ein eng gefasster erster Regelkreis bietet Ihnen eine klare Ausgangsbasis, auf der spätere Tests aufbauen können.

„HIL Tests mit der Steuerungsschnittstelle beginnen, die das höchste Risiko und die geringste Beobachtbarkeit aufweist.“

Die Auswahl der Tools beginnt mit Ihrem Budget für die Laborlatenz

Die Auswahl der Werkzeuge sollte bei dem Latenzbudget ansetzen, das Ihr Labor einhalten muss. Erst danach kommen die Funktionslisten ins Spiel. Die Ausführung mit festem Schritt, I/O und die Modellpartitionierung legen die Mindestanforderungen für hardware zuverlässige hardware fest. Sobald diese Grenzen bekannt sind, lässt sich software leichter beurteilen. Ihre Werkzeugauswahl sollte die gemessenen zeitlichen Anforderungen widerspiegeln.

Ein Desktop-Simulator reicht oft für die Wegplanung, die Kartenwiedergabe und die Offline-Optimierung des Controllers aus. Eine Plattform wie OPAL-RT kommt dann ins Spiel, wenn Ihr Modell eine Ausführung mit festem Zeitschritt gewährleisten muss, während es mit Encodern, Pulsweitenmodulationssignalen und deterministischem Netzwerkverkehr verbunden ist. Dieser Unterschied hat wenig mit der Grafik zu tun, sondern vielmehr mit der zeitlichen Kontrolle. Die richtige Wahl hängt davon ab, welchen Test Sie bestehen möchten.

Diese Checkpoint-Sichtweise sorgt dafür, dass Debatten über Werkzeuge stets an den Anforderungen im Labor ausgerichtet bleiben. Außerdem verhindert sie, dass Teams Robotik-Simulationen, Sensorsimulationen und Simulationen eingebetteter Systeme als separate Anschaffungen betrachten. Für hardware bilden sie eine einzige Testkette. Ihr Latenzbudget ist der naheliegendste Ausgangspunkt.

Durch eine schrittweise Validierung werden Forschungsprototypen für hardware vorbereitet

Die schrittweise Validierung sorgt dafür, dass Forschungsprototypen vorankommen, da in jeder Phase zunächst eine hardware geklärt wird, bevor in der nächsten Phase die Komplexität erhöht wird. Dadurch bleiben Fehler nachvollziehbar und Korrekturen kostengünstiger. Labore, die nach diesem Prinzip arbeiten, liefern fundiertere Erkenntnisse bei geringerem Versuchsaufwand. Der Prozess ist diszipliniert, wiederholbar und weckt mehr Vertrauen.

Ein Projekt zu mobilen Manipulatoren verdeutlicht den Nutzen. Das Team validiert zunächst eine einzelne Gelenkschleife mit in die Schleife eingebettetem Code, fügt dann Schätzgrößen mit Sensorverzögerung hinzu und testet anschließend die koordinierte Bewegung über den gesamten Arm und die Basis hinweg. Tritt ein Fehler auf, weiß die Gruppe bereits, in welcher Ebene er entstanden ist. Das verkürzt die Zeit für Diskussionen und verwandelt hardware in gezielte Verifizierungen statt in endloses Debugging.

Hier kommt es mehr auf die Qualität der Ausführung als auf den Umfang des Modells an. OPAL-RT fügt sich nahtlos in Labore ein, in denen bereits vor hardware Zeitbudgets, I/O und Erfolgskriterien festgelegt werden. Die Plattform unterstützt eine disziplinierte Validierung, doch der größere Vorteil liegt in der Methode, die hinter den Tests steht. Forschungsergebnisse lassen sich hardware weniger Überraschungen auf hardware übertragen, wenn der Simulationspfad stets an messbare Nachweise geknüpft bleibt.