Wie ausgereift ist die Echtzeitprogrammierung in der Robotik? [geschlossen]

Edit: Ich weiß nicht warum, aber diese Frage scheint viele Leute zu verwirren. Mir ist bewusst, wann / wo / warum / wie ich Echtzeit verwende. Ich bin daran interessiert zu wissen, ob es Leuten, die eine Echtzeitaufgabe haben, wirklich wichtig genug ist, diese in Echtzeit umzusetzen oder nicht.

Es muss nicht erwähnt werden, warum Echtzeitoperationen für einen Roboter wichtig sind. Meine Frage ist jedoch, wie viel es tatsächlich in der Robotik verwendet wird?

Nehmen Sie zum Beispiel diese Frage . In nur einer Antwort wird eine Plattform mit Echtzeitfähigkeiten erwähnt, und sie ist auch weit von der Spitze entfernt. ROS ist anscheinend eine sehr beliebte Plattform, die nicht in Echtzeit läuft.

In der Echtzeitwelt scheint RTAI ¹ jedoch die einzige funktionsfähige kostenlose Echtzeit-Nutzungsplattform zu sein. Es ist jedoch auf Linux beschränkt (kein Problem), schlecht dokumentiert und langsam entwickelt.

Wie sehr ist Echtzeitverhalten bei Robotik-Entwicklern gefragt?Die Frage ist, inwieweit Entwickler geneigt sind, Echtzeitanwendungen zu schreiben, wenn Echtzeitverhalten tatsächlich benötigt wird. Wenn nicht viel, warum?

Beispielsweise kann ein reflexives Verhalten, das auf taktilen Daten basiert, keine ROS durchlaufen, da es seine Echtzeiteigenschaft verlieren würde. Aber kommen die Leute wirklich auf eine Echtzeitlösung oder verwenden sie ROS trotzdem und ignorieren dabei die Echtzeit-Eigenschaft?

¹ oder ähnlich Xenomai

Denken Sie daran, dass es Echtzeit und Echtzeit gibt .

Harte Echtzeit ist ohne Hardwareunterstützung oder Softwareunterstützung auf niedrigem Niveau schwer zu erreichen, aber Sie brauchen oft nicht alles, um in der Lage zu sein, harte Echtzeit zu betreiben. Soft & Firm Real Time Response ist viel einfacher zu erreichen und für viele Anwendungen oft mehr als ausreichend.

Außerdem können verschiedene Teile eines Systems sehr unterschiedliche Echtzeitanforderungen haben. Wenn Sie Software-PID-Schleifen ausführen , sollten diese wirklich eine harte Echtzeitreaktion haben (Sie möchten wirklich nicht zwischen einer sanften Abstimmung Ihrer PIDs oder einer harten Abstimmung wählen müssen und sie zum Beispiel gelegentlich instabil werden lassen). Ein Bildverarbeitungssystem kann hohe Anforderungen an die Echtzeitreaktion stellen. Die Leistung wird beeinträchtigt, wenn Sie das Bild nicht rechtzeitig für die nächste Entscheidung verarbeiten können. In diesem Fall muss das System jedoch nicht am Laufen gehindert werden, wenn Sie es nicht rechtzeitig verarbeiten können Es ist besser, die Teilergebnisse wegzuwerfen und nicht die Zeit zu verlieren, mit der die Analyse im nächsten Frame beginnt. Schließlich Ihre Gesamtplanung und Koordination (wahrscheinlich die komplexesteTeil Ihres Robotersystems) kann oft fest im Bereich der weichen Echtzeit bleiben .

Selbst im Bereich von Windows-PCs können Sie eine harte Echtzeitleistung erzielen. Sie benötigen nur die richtige Software mit den richtigen Hooks im Kernel. Die TwinCat-Soft-SPS von Beckhoff hat eine SPS mit hoher Scan-Rate problemlos ausgeführt, indem sie die Hälfte der Maschinenzyklen eines Pentiums aufgeschnitten und die andere Hälfte an Windows NT übergeben hat. Dies war vor über einem Jahrzehnt. Selbst moderne Steuerungssysteme wie einige Optionen der A3200-Reihe von Aerotech erledigen die Aufgaben auf dem Host-PC, wobei der Kernel auf niedriger Ebene so viel CPU-Zeit benötigt, wie für die harten Echtzeitanforderungen erforderlich ist, und der Rest der CPU-Zyklen für Windows 7 verbleibt benutzen!

Ein Echtzeitsystem wird für viele (die meisten?) Robotersteuerungssysteme nicht wirklich benötigt. Solange Sie einen Regelkreis haben, der schnell genug ist, wenig Jitter aufweist und nicht zu viele Zyklen auslässt, ist dies für die Robotersteuerung und das Servo ausreichend.

Lassen Sie mich als Beweis dafür den PR2 und die Shadow Robot Hand vorstellen:

Dieser Roboter hat ungefähr 20 Freiheitsgrade, die alle über die Hauptschleife von ROS gesteuert werden. Oder wie wäre es mit der Shadow Robot Hand, die ebenfalls 20 Freiheitsgrade sowie eine Reihe von taktilen und anderen Sensoren hat und auch über die Hauptschleife von ROS bedient wird.

Die ROS-Hauptschleife leidet unter einem kleinen Jitter, manchmal bis zu 100us, und manchmal fehlen sogar Zyklen insgesamt. Es spielt jedoch keine Rolle, ob 99,9% der Zyklen erfolgreich ausgeführt werden.

Die Verwendung vieler Kerne in den Host-PCs bedeutet, dass ein ganzer Kern für die Ausführung der Hauptschleife vorgesehen ist und daher sehr selten durch andere Aufgaben verzögert wird.

Der Hauptgrund für die Verwendung eines Echtzeit-Betriebssystems für ein Robotersystem liegt in der Sicherheit. Wenn der Roboter in einer sicherheitskritischen Situation arbeitet, liegt es in Ihrer Verantwortung, eine 100% ige Verfügbarkeit der Steuerung zu gewährleisten, und ein Teil davon garantiert die Echtzeitnatur.

Unabhängig davon, ob Sie ein Echtzeit-Betriebssystem verwenden oder nicht, sollten Ihre Servos für den Fall, dass der Regelkreis vollständig ausfällt, etwas Sicheres tun. Dieses Sicherheitssystem ist auch in seltenen Fällen hilfreich, in denen Ihr Nicht-Echtzeit-Betriebssystem mehr als einen Zyklus überspringt. Zum Beispiel werden bei der Schattenhand die Motoren angehalten, wenn der Regelkreis mehr als 20 Zyklen (20 ms) verfehlt. Ich habe dies jedoch noch nie gesehen.

Hinzugefügt

Eine andere Möglichkeit, darüber nachzudenken, ist folgende: Welche Aktualisierungsrate benötigt Ihr Servosystem tatsächlich? Wenn es sich um einen großen Arm handelt und keine Hochleistungs-Hochgeschwindigkeitspositionierung benötigt, sind 500 Hz möglicherweise ausreichend. Zum Herumfahren reichen wahrscheinlich 200Hz aus. In beiden Fällen, wenn Ihre Schleife tatsächlich mit 1000 Hz läuft, ist ein verspäteter oder fehlender Zyklus überhaupt kein Problem, solange Ihr Steuerungsalgorithmus die tatsächlich verstrichene Zeit zwischen den Schleifen berücksichtigt.

Der Zweck der Software bestimmt, ob sie ausschließlich in Echtzeit ausgeführt werden muss.

Wenn der Zweck die Pfadplanung oder -lokalisierung ist, reicht häufig eine niedrige Frequenz aus, beispielsweise 10 Hz. In diesen Fällen ist ein Player / Stage-Setup unter Linux in Ordnung. Wir können sehen, dass es nur wenige Probleme gibt, wenn ein Zeitschritt etwas länger oder kürzer ist.

Streng Echtzeitverhalten ist erforderlich, wenn die Roboterdynamik schnell ist. Zum Beispiel, indem Sie einen Roboterarm bewegen, um eine Position zu verfolgen, oder um Objekte zu handhaben, zu greifen und zu bewegen. Wenn ein Zeitschritt versäumt wird, kann die Position unerwünscht übersteuern, und wir möchten möglicherweise ein vorhersagbareres Verhalten. In diesem Fall kann die Frequenz bis zu 1 kHz oder mehr betragen. Wenn ein Betriebssystem verwendet wird, möchten wir ein Echtzeit-Betriebssystem.

Echtzeitverhalten kann in eingebetteten Anwendungen mithilfe von Timern und Interrupts (kompilierter C-Code auf einem Mikrocontroller) erreicht werden. In diesem Fall müssen wir sicherstellen, dass die Verarbeitungslast nicht zu hoch ist, damit eine regelmäßige Abtastfrequenz eingehalten werden kann.

Roboter, die Computer / Mikroprozessoren verwenden (da mehr Rechenleistung erforderlich ist), müssen ein Echtzeit-Betriebssystem verwenden, um hohe Abtastraten zu gewährleisten.

Ob Echtzeitverhalten erforderlich ist, hängt daher davon ab, wofür der Entwickler es verwenden möchte.

Unser Unternehmen baut Roboter mit FreeRTOS auf PIC-Mikrocontrollern. Für uns sind die Hauptgründe für die Verwendung von FreeRTOS die einfache Neuordnung der Prioritäten für Aufgaben, die gleichzeitige Verarbeitung mehrerer Kommunikationsleitungen und die einfache Kommunikation zwischen Interrupt-Handlern und Hauptaufgaben. Mikrocontroller sind weitaus billiger als der Einbau einer vollständigen Linux-Maschine in jeden von uns hergestellten Roboter.

Wenn Sie tatsächlich Echtzeit benötigen, verwenden Sie ein Echtzeit-Betriebssystem. Sicherheitsüberwachung, Datenerfassung und Regelkreise für konstante Abtastraten sind gängige Subsysteme, die Echtzeitplanung verwenden.

Der Echtzeitanteil der Programmierung ist normalerweise so gering wie möglich, da das Debuggen schwieriger ist und weniger Code leichter auf Richtigkeit überprüft werden kann. Die Dokumentation zu Echtzeitbetriebssystemen ist normalerweise ziemlich gut (einschließlich RTAI / Xenomai).

Ich habe QNX und RTAI-> Xenomai in verschiedenen realen Robotikprojekten verwendet. Ich habe QNX vorgezogen, aber Xenomai war genauso effektiv.

Orocos ist ein ausgereiftes Echtzeit-Framework für Robotersteuerungssoftware. Ich habe gesehen, dass es verwendet wurde, um Hochgeschwindigkeits-Robotermanipulatoren mit harten Echtzeitanforderungen erfolgreich zu steuern. Es enthält viele der gleichen Komponenten auf Framework-Ebene wie ROS, Kommunikation, Konfiguration, Serialisierung und komponentenbasiertes Packaging.

Denken Sie an Ihren Roboter in Bezug auf mehrere CPUs, und die Echtzeitfrage verschiebt sich. Wenn Sie über einen Algorithmus verfügen, der eine zuverlässige Hochgeschwindigkeitsrückmeldung benötigt, z. B. eine Zweiradauswuchtmaschine oder einen Quad-Copter-Stabilisator oder einen Servo-Impulsausfall, ist die Echtzeit äußerst wichtig, aber die Aufgabe ist auch sehr eingeschränkt.

Sie können einen Regelkreis wie diesen auf eine dedizierte Echtzeit-CPU auslagern, z. B. die billigen 8-Bit-AVR- oder Low-End-32-Bit-ARMs der Arduino-Geräteklasse. Es hindert Sie nichts daran, viele Dutzend dieser kleinen MCUs mit dedizierten Regelkreisen hinzuzufügen. Die Aufzählung von USB-Geräten macht dies sogar noch einfacher.

Jetzt, da die zeitabhängigen Regelkreise von einer dedizierten CPU verwaltet werden, können Sie die Echtzeitanforderungen des „Gehirns“ des Roboters, das mithilfe von Komponenten wie ROS unter Linux oder Kinect für Windows High-End-Logik ausführen kann, lockern.

In Reaktion auf "wann / in welchem ​​Fall" werden Echtzeitsysteme verwendet:

Nach meiner Erfahrung ist die Bewegungssteuerung die Hauptanwendung für Echtzeitsysteme. Für die Steuerung von Motoren sind eine hohe Frequenz (100 Hz, 1000 Hz und mehr) und ein geringer Jitter (Zeitschwankungen) wichtig. Sicherheit ist hier ein wichtiger Punkt. Stellen Sie sich einen Roboter unter Menschen vor: Sie möchten / müssen beispielsweise sicherstellen, dass der Roboter (Arm) in einem bestimmten Zeitrahmen / Abstand anhält.

Für andere Aufgaben wie die Pfadplanung, die Bildverarbeitung und die Argumentation ist das Echtzeitsystem nicht so wichtig und wird häufig vermieden, da die Entwicklungszeit und die Hardwarekosten zu hoch sind.

Große Roboter wie der PR2 verbinden heutzutage beide Welten. Im Echtzeitkontext des RT-fähigen Betriebssystems (z. B. Linux + Xenomai) findet eine Bewegungssteuerung statt, und im Nicht-Echtzeitteil (Benutzerland) sind die Bildverarbeitung und -planung in Systeme wie ROS eingebettet. Beide können auf demselben Computer ausgeführt werden.

Ich bearbeite diese Antwort gerne, sobald die Frage geklärt ist. :-)

Ja, vorausgesetzt, die Hardwareressourcen können die Timing-Anforderungen erfüllen (ausreichend Rechenleistung, ausreichend niedrige Latenz). Wenn der Scheduler Prozesse und Threads nicht ordnungsgemäß sequenzieren kann, wird ein Echtzeit-Scheduler verwendet, der normalerweise mit einem speziell für den Kernel optimierten Kernel verbunden ist Herausforderungen dieses. Hardwaretreiber können auch für Echtzeitbedingungen optimiert werden.

Ja, wenn nicht garantiert werden kann, dass eine Software ihre Arbeit in der erforderlichen Zeit erledigt, verwendet man Echtzeitansätze.

Eine gute Lösung ist, BEIDES zu tun. Ein Design, das ich benutze, um "harte" Echtzeitfunktionen auf einem kleinen Mikrocontroller, engen Servo-Regelkreisen und dergleichen zu platzieren. Dann gibt es eine andere CPU, die größer ist und Linux und ROS ausführt. Ich überlasse es ROS, die übergeordneten Aufgaben zu erledigen, und dem uP, Dinge wie die Steuerung eines Schrittmotors oder die Ausführung eines PID-Regelkreises zu erledigen.

Wie bereits von anderen erwähnt, KÖNNEN Sie einem Nicht-Echtzeit-Betriebssystem erlauben, 1-kHz-Regelkreise auszuführen. Damit dies funktioniert, benötigen Sie jedoch einen übergroßen Computer, der die meiste Zeit in einer Leerlaufschleife verbringt. Wenn Sie den Linux / ROS-Computer mit nahezu 100% CPU-Auslastung betreiben, ist die Echtzeitleistung schlecht. Die Verwendung eines zweistufigen Designs ermöglicht es Ihnen, immer eine sehr gute RT-Leistung zu erzielen und auch einen kleineren, stromsparenderen Computer (möglicherweise einen Pi2-Computer höherer Ebene) zu verwenden. Mein uP führt derzeit kein Betriebssystem aus, aber ich wechsle zu FreeRTOS