Eine zuverlässige und schnelle Kommunikation erfordert eine geeignete Netzwerkarchitektur

Einleitung: Humanoide Roboter als EtherCAT-Applikation

Humanoide Roboter zählen zu den anspruchsvollsten Anwendungen, die sich mit EtherCAT realisieren lassen. Auf engstem Raum vereinen sie Dutzende synchronisierter Servoachsen, Echtzeit-Sensorik und rechenintensive KI-Verarbeitung. Entscheidend ist dabei vor allem eines: Zuverlässigkeit. In Armen und Beinen werden die Leitungen bei jeder Bewegung gebogen und verdreht – Kabelbrüche können im schlimmsten Fall einen Sturz auslösen. Eine Junction im Rumpf löst dieses Problem elegant: Mit Junction-Redundanz lässt sich jede Extremität lokal zum Ring schließen, das zusätzliche Kabel führt nur bis zur Junction zurück. So lassen sich Kabelredundanz und geringes Gewicht vereinbaren.

Allein für Rumpf, Arme, Beine sowie Hände und Greifer sind je nach Konstruktion 40 bis 80 Antriebe erforderlich. Nicht jeder Antrieb benötigt ein eigenes EtherCAT SubDevice, da ein SubDevice oft mehrere Achsen ansteuert. In Summe kommen dennoch rund 30 bis 50 SubDevices zusammen, ergänzt um weitere Geräte für Sensoren und Aktoren wie IMUs, Kraft-Momenten-Sensoren oder Gelenkencoder.

In diesem Blog zeigen wir anhand eines konkreten Testaufbaus, wie drei Softwarekomponenten von acontis auf einem NVIDIA Jetson AGX Thor Developer Kit zusammenspielen: die EtherCAT MainDevice Software EC-Master, die Netzwerksimulation EC-Simulator und das browserbasierte Konfigurations- und Diagnosetool EC-EngineerWeb. Im Mittelpunkt steht die Junction-Redundanz: In fünf praktischen Tests zeigen wir, wie EC-Master einen Kabelbruch im Bein abfängt, wie EC-EngineerWeb ihn sichtbar macht und wie sich solche Fehler mit EC-Simulator vorab ohne Hardware testen lassen.

Die Plattform: NVIDIA Jetson AGX Thor

Als Steuerungsplattform dient im Testaufbau das NVIDIA Jetson AGX Thor Developer Kit. NVIDIA hat Jetson AGX Thor gezielt für Physical AI und humanoide Robotik entwickelt: Die Plattform führt KI-Modelle für Wahrnehmung, Planung und Sprache direkt im Roboter aus. In der Architektur eines Humanoiden unterscheidet NVIDIA zwischen KI-Schichten für Wahrnehmung, Planung und Reasoning und einer Echtzeit-Regelung, die minimale und vorhersagbare Latenzen verlangt. Genau diese Schicht deckt EC-Master ab: Er verbindet die Regelungssoftware deterministisch mit allen Antrieben und Sensoren des Roboters.

Dass beide Welten auf derselben Hardware zusammenpassen, hat acontis im Blog Thor meets EtherCAT – acontis EC-Master on NVIDIA Jetson AGX Thor vorgestellt. Ausgangsbasis ist das Linux aus NVIDIA JetPack: Dazu wird der mitgelieferte Echtzeit-Kernel installiert, ein CPU-Kern exklusiv für EC-Master reserviert, und alle Kerne laufen mit maximaler Taktfrequenz. In der leistungsfähigsten Variante ersetzt der acontis Echtzeit-Ethernet-Treiber zusätzlich den Linux-Standardtreiber und greift über das Kernelmodul atemsys direkt auf den Ethernet-Controller zu.

Die Softwarekomponenten im Überblick

Drei Werkzeuge von acontis decken im Testaufbau den gesamten Entwicklungszyklus ab – von der Simulation über den Betrieb bis zur Diagnose:

Testaufbau

Da uns bei acontis derzeit keine 40 oder mehr Antriebe zur Verfügung stehen, bilden wir das Netzwerk eines Humanoiden mit einer Mischung aus Antrieben und I/O-Modulen nach. Das Testnetzwerk besteht aus:

• einer Beckhoff Junction CU1128, die im Netzwerk als 3 SubDevices erscheint,
• je 9 SubDevices für den linken und den rechten Arm,
• je 11 SubDevices für das linke und das rechte Bein.

Das jeweils erste SubDevice an Armen und Beinen ist ein Antrieb mit aktivierten Distributed Clocks. Die übrigen SubDevices sind analoge und digitale Ein- und Ausgangsmodule. In Summe umfasst das Netzwerk 43 SubDevices mit rund 694 Byte Eingangs- und 694 Byte Ausgangsdaten; der zyklische Frame ist insgesamt 1434 Byte lang. Als MainDevice mit EC-Master dient das NVIDIA Jetson AGX Thor Developer Kit.

Synchrone Antriebe dank Distributed Clocks

Flüssige Bewegungen setzen voraus, dass alle Antriebe exakt synchron arbeiten. Die Steuerung übergibt die Sollwerte in einem Zyklus von 1 ms oder weniger, je nach Antrieb im CSP-, CSV- oder CST-Mode. Die Grundlage bildet Distributed Clocks (DC): EC-Master gleicht die Uhren aller SubDevices auf eine gemeinsame Systemzeit ab und kompensiert dabei die Signallaufzeiten. So übernehmen alle Antriebe ihre Sollwerte zum exakt gleichen Zeitpunkt – ohne spezielle Hardware am MainDevice.

Netzwerktopologie: Stern mit Junction

EtherCAT unterstützt nahezu jede Topologie – Linie, Daisy Chain, Stern, Baum und Stichleitungen – sowie beliebige Kombinationen daraus. Die Netzwerkperformance ist dabei weitgehend unabhängig von der gewählten Struktur. Da EtherCAT keine Infrastrukturkomponenten wie Switches oder Hubs benötigt, spart die Technologie im Humanoiden Bauraum, Gewicht und Verkabelungsaufwand.

Für einen klassischen Humanoiden mit zwei Armen und zwei Beinen bietet sich eine Sterntopologie an, da die Steuerung in der Regel zentral im Rumpf sitzt. Ebenfalls im Rumpf – häufig direkt als erstes SubDevice – verteilt eine Junction das Netzwerk auf Arme und Beine. Eine Junction ist kein Switch: Sie leitet die Frames ohne Zwischenspeicherung an ihre Ports weiter, das logische Ringprinzip von EtherCAT bleibt erhalten. Im Testaufbau verwenden wir die Beckhoff Junction CU1128.

Junction-Redundanz für Arme und Beine

Besonders folgenschwer ist ein Kabelbruch in Armen oder Beinen, wo die Leitungen ständig bewegt werden. Vor allem die Beine sind kritisch: Ein Kabelbruch kann dort einzelne oder mehrere Antriebe abrupt stoppen. Geht der Humanoid gerade, kann er je nach Geschwindigkeit und Konstruktion stürzen. Denn Gehen ist im Grunde ein kontrollierter Fall – fehlt die Kontrolle, ist der Sturz kaum zu verhindern.

Um die Beine abzusichern, bietet sich Junction-Redundanz an. Dabei wird jede Stichleitung lokal zum Ring geschlossen: Vom letzten SubDevice führt ein zusätzliches Kabel zurück an die Junction. Im Testaufbau hängt das linke Bein an Port X2 und das rechte Bein an Port X6; die Redundanzkabel führen zurück an X3 und X7. EC-Master unterstützt solche lokalen Ringe auch in Kombination mit Distributed Clocks – bei einer Unterbrechung im Ring bleibt der Roboter betriebsbereit.

Mit Junction-Redundanz für beide Beine sind sieben der acht Ports der Junction CU1128 belegt (Topologie 2). Sollen zusätzlich beide Arme abgesichert werden, reicht der freie Port X8 nicht aus; dann ist eine weitere Junction erforderlich. Auch diese Konfiguration mit weiteren lokalen Ringen unterstützt EC-Master.

Junction-Redundanz nur für einen Teil der Beine

Nicht immer muss eine komplette Extremität redundant angebunden sein. Es ist auch möglich, im lokalen Ring eine weitere Junction einzubauen und daran über eine Stichleitung (Branch) weitere SubDevices anzuschließen. Im Beispiel bilden die ersten fünf SubDevices jedes Beins zusammen mit der Junction CU1128 einen lokalen Ring. Das fünfte SubDevice dient zugleich als Junction: An ihm hängen die übrigen sechs SubDevices an einer Stichleitung ohne Redundanz (Topologie 3). Ein Kabelbruch im Ring bleibt folgenlos, ein Bruch in der Stichleitung trennt dagegen die SubDevices dahinter vom Netzwerk. So lässt sich die Redundanz gezielt auf einen Teil der Beine beschränken. In den folgenden Tests verwenden wir nur die Topologien 1 und 2.

Ob ein Redundanzkonzept im Ernstfall greift, lässt sich am realen Roboter nur schwer und mit Risiko prüfen. Hier hilft EC-Simulator: Er bildet das komplette Netzwerk virtuell nach und erzeugt Kabelbrüche, SubDevice-Ausfälle und weitere Fehlerzustände gezielt – auch solche, die sich in Hardware kaum reproduzieren lassen.

Softwarearchitekturen

Alle Softwarekomponenten laufen direkt auf dem Jetson AGX Thor. Die EtherCAT-Applikation EcMasterDemoDc mit EC-Master ist fest dem CPU-Kern 2 zugeordnet. EC-EngineerWeb läuft getrennt davon auf CPU-Kern 5 und stört den Echtzeitzyklus damit nicht. Über das Remote Access System (RAS) verbindet sich EC-EngineerWeb mit dem laufenden EC-Master: Der RAS-Server läuft neben EcMasterDemoDc auf CPU 2, der RAS-Client ist Teil von EC-EngineerWeb auf CPU 5. Auf dem Laptop ist keine Installation nötig: Ein Webbrowser mit der IP-Adresse des Boards und Port 5000 genügt.

Bei SWA1 kommuniziert EC-Master über den acontis Treiber emllDwXgmac und einen Ethernet-Port des Jetson AGX Thor, den MainPort, mit dem realen Testnetzwerk.

Bei SWA2 ersetzt EC-Simulator den Ethernet-Treiber. EC-Master übergibt jedes Frame an den Simulator-Treiber emllSimulator, der es an die simulierten SubDevices weiterreicht und wieder zurückgibt. Ethernet-Schnittstellen und Kabel werden nicht benötigt. Die simulierten SubDevices durchlaufen die EtherCAT State Machine bis OP und unterstützen Distributed Clocks – für EC-Master ist kein Unterschied zum realen Netzwerk erkennbar. Für die Diagnose stellen EC-Master und EC-Simulator je einen eigenen RAS-Server bereit, auf Port 6000 und Port 6001; EC-EngineerWeb kann sich mit beiden verbinden.

Tests

Die Tests 1 bis 3 laufen mit SWA1 im realen Netzwerk, die Tests 4 und 5 mit SWA2 im EC-Simulator.

Test 1: Reales Netzwerk mit Standardverkabelung

Hier läuft das Netzwerk in Topologie 1 ohne Redundanz. EcMasterDemoDc startet das Netzwerk mit aktiven Distributed Clocks und fährt alle SubDevices in den Zustand OP. Anschließend geht EC-EngineerWeb online.

EcMasterDemoDc -v 3 -a 2 -b 1000 -f "Humanoid.xml" -sp 6000 -dwxgmac 1 1 jetson-agx-thor

Im Diagnose-Modus zeigt die Topologieansicht von EC-EngineerWeb das gesamte Netzwerk grafisch: das MainDevice (M1), die Junction mit ihren drei SubDevices sowie die Linien für Arme und Beine. Rechts zeigt der Reiter General den Zustand des ausgewählten SubDevice: aktueller und angeforderter Zustand der EtherCAT State Machine – hier Op –, Schaltflächen zum Wechsel des Zustands sowie die Software- und Hardware-Diagnose mit dem Fehlerstatus jedes Ports.

Test 2: Reales Netzwerk mit Junction-Redundanz-Verkabelung

Hier ist das Netzwerk nach Topologie 2 verkabelt: Zusätzlich zu den Leitungen an X2 und X6 sind beide Beine über X3 und X7 als lokale Ringe an die Junction angebunden. Der Parameter -junctionred aktiviert die Junction-Redundanz in EcMasterDemoDc.

EcMasterDemoDc -v 3 -a 2 -b 1000 -f "Humanoid.xml" -sp 6000 -junctionred -dwxgmac 1 1 jetson-agx-thor

In der Classic View listet EC-EngineerWeb alle SubDevices in einer Baumstruktur – vom MainDevice über die Junction CU1128 bis zu den einzelnen SubDevices der Arme und Beine. Rechts zeigt der Reiter Variables die Prozessdaten des ausgewählten SubDevice mit Datentyp, Offset im Prozessabbild und aktuellem Wert. Den Verlauf eines Kanals stellt EC-EngineerWeb als Chart dar.

Test 3: Was passiert bei einem Kabelbruch?

Im realen Netzwerk mit Topologie 2 unterbrechen wir im rechten Bein die Verbindung zwischen SubDevice 1033 und SubDevice 1034, um einen Kabelbruch nachzustellen. EC-Master erkennt die Topologieänderung. Dabei können ein bis zwei Frames verloren gehen, ansonsten bleiben alle SubDevices erreichbar und im Zustand OP, und die Prozessdaten laufen weiter: Die SubDevices hinter der Unterbrechung erreicht EC-Master jetzt über das Redundanzkabel an Port X7 der Junction.

Im Logfile von EC-Master werden dazu folgende Meldungen aufgezeichnet:

Junction redundancy change (Line break = 1) - Slave Right-Leg-Device2: - EtherCAT address=1034 at port 0
Bus scan successful - 43 slaves found
Topology Change Performed No Error (0x0)

Die erste Meldung zeigt den erkannten Leitungsbruch an Port 0 von Right-Leg-Device2 (EtherCAT-Adresse 1034), also am Eingang zum vorherigen SubDevice 1033. Der anschließende Bus-Scan findet weiterhin alle 43 SubDevices, und EC-Master schließt die Topologieänderung ohne Fehler ab.

Auch in EC-EngineerWeb ist der Kabelbruch sofort sichtbar: Ein Warnsymbol mit Ausrufezeichen im Baum markiert Right-Leg-Drive1 und Right-Leg-Device2 – die beiden SubDevices direkt an der Unterbrechung, an deren Ports ein Fehler erkannt wurde. Alle SubDevices sind weiterhin grün markiert und damit erreichbar, und der Chart zeigt, dass die Prozessdaten von Right-Leg-Device2 weiterlaufen.

Test 4: Simuliertes Netzwerk mit Junction-Redundanz-Verkabelung

Hier läuft Topologie 2 im EC-Simulator (SWA2). EC-Master und EC-Simulator verwenden dabei dieselbe Konfigurationsdatei.

EcMasterDemoDc -f "Humanoid.xml" -b 1000 -sp 6000 -v 3 -a 2 -junctionred -simulator 1 1 Humanoid.xml --sp 6001

In EC-EngineerWeb erscheint das simulierte Netzwerk im Baum unter dem Knoten EC-Simulator. Der Reiter Variables zeigt die Eingänge der simulierten SubDevices – und diese lassen sich direkt setzen: Im Beispiel wird beim simulierten Right-Leg-Device2 der Eingangskanal CH3 über Force auf den Wert 4 gesetzt, der Chart zeigt den Sprung von 0 auf 4. EC-Master liest diesen Wert wie einen echten Eingang ein. So lässt sich das Verhalten der Applikation bei bestimmten Sensorwerten gezielt testen, ohne dass ein reales Signal anliegen muss.

Test 5: Fehlersituationen simulieren mit EC-Simulator und EC-EngineerWeb

Ein Roboter muss auch mit Störungen zuverlässig umgehen: Ein SubDevice verliert seine Versorgungsspannung, ein Stecker löst sich, ein Kabel bricht. Solche Situationen am realen Aufbau herbeizuführen, ist aufwendig, riskant und kaum exakt wiederholbar. EC-EngineerWeb bietet deshalb eine Funktion, mit der sich Fehlerszenarien im EC-Simulator kontrolliert und reproduzierbar auslösen lassen – zum Beispiel den Spannungsausfall eines SubDevice oder das Trennen einer Kabelverbindung. So lässt sich gezielt prüfen, wie EC-Master und die Applikation auf jede einzelne Störung reagieren, ohne die Hardware zu gefährden.

Mit diesem Test prüfen wir das Redundanzkonzept von Topologie 2 im EC-Simulator (SWA2). Der Aufruf entspricht Test 4:

EcMasterDemoDc -f "Humanoid.xml" -b 1000 -sp 6000 -v 3 -a 2 -junctionred -simulator 1 1 Humanoid.xml --sp 6001

Die Störungen löst man in EC-EngineerWeb im Reiter Simulator des jeweiligen SubDevice aus.

• SubDevice: Mit Power off und Power on lässt sich ein Spannungsausfall des SubDevice nachbilden. Über Requested State und Error Code versetzt Set Sim State das simulierte SubDevice gezielt in einen anderen Zustand, auf Wunsch mit Fehlercode. Außerdem kann das SubDevice eine CoE-Emergency-Meldung mit frei wählbarem Code und Daten senden.
• Simulate cable break: Für jeden Port zeigt der Dialog, mit welchem benachbarten SubDevice er verbunden ist. Disconnect trennt diese Verbindung, Connect stellt sie wieder her – ein Kabelbruch auf Knopfdruck.
• Simulate intermittent errors: Für sporadische Fehler, etwa durch schlechte Steckverbinder oder EMV-Störungen, lässt sich pro Port eine instabile Verbindung mit einstellbarer Ausfallzeit simulieren, oder es werden fehlerhafte Frames erzeugt – jeweils dauerhaft oder zufällig mit einer vorgegebenen Wahrscheinlichkeit.

Im Reiter Simulator von EC-EngineerWeb lösen wir unter „Simulate cable break“ mit Disconnect gezielt eine Unterbrechung im Netzwerk aus – an derselben Stelle wie in Test 3: Bei Right-Leg-Device2 trennen wir Port 0, also die Verbindung zu Right-Leg-Drive1 (1033). Der Dialog zeigt Port 0 danach als „Not Connected“. Dank der Junction-Redundanz erreicht EC-Master alle SubDevices weiterhin, und das Netzwerk bleibt im Zustand OP.

Funktionale Sicherheit mit FSoE

Arbeiten humanoide Roboter in der Nähe von Menschen, rückt die funktionale Sicherheit in den Fokus. Weit verbreitet ist dafür Safety over EtherCAT (FSoE): Die sicherheitsrelevanten Daten werden nach dem Black-Channel-Prinzip im selben EtherCAT-Frame wie die Standarddaten übertragen, eine separate Safety-Verkabelung entfällt. Für FSoE spielt die Topologie deshalb keine Rolle – es funktioniert bei allen gezeigten Topologien, mit und ohne Junction-Redundanz, und lässt sich mit EC-Master uneingeschränkt verwenden. Auf der Plattform NVIDIA IGX Thor hat acontis gemeinsam mit Partnern bereits FSoE-Lösungen umgesetzt.

Fazit: Zuverlässig ausgelegt – getestet, bevor der Roboter fällt

Ein humanoider Roboter verzeiht keinen Kommunikationsausfall: Gehen ist ein kontrollierter Fall, und reißt die Verbindung zu einem Bein ab, kann daraus ein echter Sturz werden. Unser Testaufbau zeigt, wie sich genau das mit Standardkomponenten verhindern lässt. Mit Junction-Redundanz an der Beckhoff Junction CU1128 fing EC-Master einen realen Kabelbruch im rechten Bein ab: Bis auf ein bis zwei verlorene Frames blieben alle 43 SubDevices im Zustand OP – bei aktiven Distributed Clocks und ohne zweiten Ethernet-Port am MainDevice. EC-Master, die Diagnose und die KI-Anwendungen des Roboters laufen dabei auf einem einzigen Jetson AGX Thor.

Derselbe Aufbau unterstützt auch den Entwicklungsablauf. Mit EC-Simulator testen Entwickler ihre MainDevice-Applikation gegen ein simuliertes Netzwerk – einschließlich Kabelbrüchen, Spannungsausfällen und sporadischen Fehlern –, noch bevor der komplette Roboter verfügbar ist. Anschließend läuft dieselbe Applikation mit den Ethernet-Treibern von EC-Master auf realer Hardware, und EC-EngineerWeb liefert in beiden Umgebungen die Diagnose. So können Teams früher mit Integrationstests beginnen, Fehler reproduzierbar nachstellen und sind weniger auf vollständige Prototypen angewiesen.

Quellen

• acontis: EtherCAT and Real-Time Software for Humanoid Robotics Applications
• acontis: acontis + NVIDIA – AI-Powered EtherCAT for the Next Generation of Robotics
• acontis Blog: Thor meets EtherCAT – acontis EC-Master on NVIDIA Jetson AGX Thor
• acontis Blog: Ready for humanoid development? Diagnosis with EC-EngineerWeb on the NVIDIA Jetson AGX Orin
• acontis: EC-Master Junction-Redundancy
• NVIDIA Technical Blog: Introducing NVIDIA Jetson Thor, the Ultimate Platform for Physical AI