Wie kann ich ein schnelles (200Hz) Echtzeitsystem mit einem langsamen (30Hz) System steuern?

Wir entwerfen derzeit einen mobilen Roboter + montierten Arm mit mehreren kontrollierten Freiheitsgraden und Sensoren.

Ich denke über eine Architektur in zwei Teilen nach:

1. Eine Reihe von Echtzeit-Controllern (entweder Raspeberry Pis mit einem RTOS wie Xenomai oder Bare-Metal-Mikrocontroller) zur Steuerung der Armmotoren und Encoder. Nennen wir diese Maschinen RTx mit x = 1,2,3… abhängig von der Anzahl der Mikrocontroller. Dieser Regelkreis läuft mit 200Hz.

2. Eine leistungsstarke Vanilla-Linux-Maschine, auf der ROS ausgeführt wird, um SLAM, Mocap und High-Level-Logik zu berechnen (bestimmen Sie die Aufgabe des Roboters und berechnen Sie die gewünschte Position und Geschwindigkeit der Motoren). Dieser Regelkreis läuft mit 30Hz.

Ich weiß, dass mein Framework skalierbar sein muss, um mehr Motoren, mehr Sensoren und mehr PCs (z. B. für externe Mocaps) zu berücksichtigen.

Mein Hauptproblem ist die Entscheidung, wie die verschiedenen RTx mit PC1 kommunizieren sollen. Ich habe mir Artikel über Roboterarchitektur angesehen (z. B. HRP2) ) angesehen, meistens beschreiben sie die Steuerungsarchitektur auf hoher Ebene, aber ich habe noch keine Informationen gefunden, wie die Kommunikation auf niedriger Ebene mit der auf hoher Ebene und auf skalierbare Weise erfolgen kann. Habe ich etwas verpasst?

Um die schnellen RT-Maschinen, die die Motorsteuerung gewährleisten, mit PC1 zu verbinden, habe ich TCP / IP, CAN und UART in Betracht gezogen:

• TCP / IP: nicht deterministisch, aber einfach einzurichten. Ist Nicht-Determinismus ein echtes Problem (da es sowieso nur bei langsamer Geschwindigkeit 30 Hz verwendet wird)?
• CAN: langsam, sehr zuverlässig, auf Autos ausgerichtet (es gibt einige Beispiele, die CAN mit Robotern verwenden, aber es sah exotisch aus)
• UART: Wenn ich nur eine RT-Maschine für die Motorsteuerung gehabt hätte, hätte ich UART in Betracht gezogen, aber ich denke, dieser Port lässt sich mit vielen RTx nicht gut skalieren. Ist TCP / IP aufgrund seiner nicht deterministischen Eigenschaften wirklich ein No-Go? Es ist so einfach zu bedienen ...

Im Moment scheint mir keine Lösung wirklich offensichtlich zu sein. Und da ich mit einer bestimmten zuverlässigen und skalierbaren Lösung kein seriöses Roboterbeispiel finden kann, bin ich nicht zuversichtlich, eine Wahl zu treffen.

Hat jemand eine klare Sicht auf diesen Punkt oder Literatur darauf hinzuweisen? Gibt es typische oder gängige Kommunikationslösungen für Roboter?

Ich denke, Sie haben einen guten ersten Schritt getan. Sie haben das Problem in eine mobile Plattform (die Positionsunsicherheiten aufweist und navigieren muss) und in den Arm (der über Encoder eine angemessene Positionssicherheit in Echtzeit aufweist) unterteilt.

Ich habe mir Artikel über Roboterarchitektur angesehen, [...] aber ich habe noch keine Informationen darüber gefunden, wie die Low-Level-Kommunikation mit der High-Level-Kommunikation auf skalierbare Weise erfolgen kann. Habe ich etwas verpasst?

Ihrer Beschreibung nach scheint es, als wollten Sie jeden RTx-Controller direkt mit PC1 verbinden, auf dem ROS ausgeführt wird. Was Sie vermisst haben, ist, dass ROS entworfen wurde eine Gruppe von Anwendungen zu behandeln , die produzieren können und verbrauchen Daten mit unterschiedlichen Raten.

Was Ihre Anwendung benötigt, ist eine Kommunikationsbrücke - eine einzige Schnittstelle zwischen Ihrer 200-Hz-Schleife und Ihrer ROS-Umgebung. Mit anderen Worten, anstatt jeden RTx-Controller an PC1 zu binden, binden Sie alle RTx-Controller zusammen und verbinden Sie diese mit PC1.

Verwenden Sie beispielsweise einen I2C-Bus , um die RTx-Systeme miteinander zu verbinden, und fügen Sie einen weiteren RTx-Controller als "Arm Master" (AM) hinzu. Die Aufgabe des AM wäre es, eingehende Befehle in einem PC1-freundlichen Format und Protokoll zu akzeptieren und diese Befehle in I2C-Nachrichten umzuwandeln. Dann würden Sie eine ROS-App schreiben, um Befehle an den AM zu senden.

Eine andere Möglichkeit, dies mit I2C zu tun, besteht darin, einen I2C-Controller direkt auf PC1 zu platzieren und die gesamte Logik zur Steuerung des Arms in eine ROS-App zu schreiben. Dies scheint eine effizientere Möglichkeit zu sein, um Ihr Ziel zu erreichen, aber es kann das Debuggen erschweren, wenn Sie die Modularität des Systems aufheben. Sie müssen es als ein großes komplexes System anstatt als zwei leicht testbare Komponenten behandeln.

Ich würde sagen, dass jede Anwendung, bei der eine große Anzahl von Kommunikationsknoten erforderlich ist (Sensoren oder Aktoren), aufgrund des Verkabelungsaufwands, des Determinismus und der Tatsache, dass sie als Systembus implementiert werden (im Gegensatz zu Punkt-zu-Punkt-Verbindungen wie UART oder Ethernet), von Vorteil ist Modularität.

Jedes Steuersystem erfordert ein hohes Maß an Determinismus, bei dem Kanäle mit hoher Bandbreite (wie z. B. Ethernet) normalerweise schlecht sind (insbesondere bei Verwendung mit einem Allzweck-Betriebssystem, das große Mengen an Scheduling-Jitter einführt). Weitere Informationen zum Scheduling-Determinismus finden Sie unter dem folgenden Link ). Anwendungsprozessoren (wie der ARM11 des Raspberry Pi) eignen sich wahrscheinlich auch schlecht für Echtzeitsysteme (aufgrund von Effekten wie Interrupt-Latenz und Anweisungs-Pipeline). In der folgenden digikey-Diskussion wird das Echtzeitverhalten eines ARM-Anwendungskerns mit einem Mikrocontroller verglichen .

Es ist eine Schande, dass die Verfügbarkeit von integriertem CAN nicht so weit verbreitet ist wie UART (RS-485) oder I2C (noch), da dies meiner Meinung nach das Problem der verteilten Erfassung und Ansteuerung wirklich vereinfacht. Auch wenn die üblichen 1 Mbit / s langsam erscheinen mögen, ist sie in der Regel mehr als ausreichend, nachdem die Aktualisierungsraten aller Busmitglieder berechnet wurden (und die Übertragungsrate kann immer erhöht werden, abhängig von der Buslänge, der Impedanz und davon, ob Ihre Transceiver dies zulassen). Es gibt auch eine brillante Simulationssoftware, die im Grunde genommen die Reaktionszeiten im schlimmsten Fall garantiert (RealTime-at-Work verfügt beispielsweise über einen kostenlosen CAN-Bus-Analysator namens RTaW-Sim). Und schließlich scheint die Verfügbarkeit von MEMS-Sensoren mit integriertem CAN eher gering zu sein.

Ein weiteres Beispiel, bei dem Aktoren als Bus (oder Ring) konfiguriert sind, sind die Dynamixel AX- und MX-Serien, bei denen jeder Motor über eine UART-Verbindung mit dem nächsten verkettet ist. Dies vereinfacht das Systemdesign erheblich, wenn Sie über eine große Anzahl von Stellgliedern verfügen.

Um jedoch auf die eigentliche Frage zurückzukommen: Ich denke, wenn Sie Ihr System als Echtzeit-Sollwerte beschreiben, anstatt als Befehle (z. B. statt eines Befehls wie goto angle einen Motorwinkel fortlaufend zu senden), wird die Kopplung zwischen den Befehlen vereinfacht die 200 Hz und 30 Hz Schleife.

Sie haben anscheinend zwei separate (aber verwandte) Probleme, die Sie gleichzeitig lösen möchten. Lassen Sie uns Ihr Rätsel in kleinere Teile zerlegen:

1. Wie kommuniziere ich Befehle von einem langsamen System (30 Hz) an einen schnellen Controller (200 Hz) und wie kommuniziere ich Daten, die mit 200 Hz empfangen werden, zurück an meinen 30-Hz-Thin-Tank?
2. Wie steuere ich , was bei 200 Hz passiert, wenn ich dem Roboter nur sagen kann, was bei 30 Hz zu tun ist?

Punkt 1 kann in Hardware gelöst werden, da Ihre ursprüngliche Frage zu deuten scheint. Sie können Daten mit 200 Hz in die Warteschlange stellen und das Paket mit 30 Hz an Ihr übergeordnetes System senden. Sie können dies mit TCP / IP oder möglicherweise CAN tun, je nachdem, wie viele Daten Sie senden möchten. Unterschiedliche Hardware hat unterschiedliche maximale Datenraten. Das Hinzufügen einer Architekturebene wie ROS als Kommunikationsbrücke / Arbiter, wie in anderen Beiträgen vorgeschlagen, kann ebenfalls hilfreich sein.

Punkt 2 ist ein steuerungstheoretisches Problem, das mit Hardware allein nicht gelöst werden kann. Der SLAM, die Positions- und Geschwindigkeitsermittlung und die Aufgabenermittlung, die Sie möchten, müssen intelligenter sein, da sie weniger häufig Informationen senden und empfangen. Sie werden wahrscheinlich 2 Regelkreise benötigen : 1 bei 200 Hz und 1 bei 30 Hz.

Es gibt viele andere Fragen, die sich mit Feed-Forward-, Feed-Back- und PID-Regelkreisen befassen, aber Sie haben speziell Fragen zur Skalierbarkeit gestellt - die meisten riesigen Systeme skalieren, indem Sie Regelkreise und Logik so überlagern , dass die minimal erforderlichen Informationen über die gesamte Hardware gehen Sie landen mit. Zum Beispiel gibt Ihr Controller der obersten Ebene möglicherweise nur Zielpositionspunkte und eine durchschnittliche Zielgeschwindigkeit an die unterste Ebene weiter, nicht aber die Geschwindigkeit 30-mal pro Sekunde.