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

20

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 1 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?

1 oder ähnlich Xenomai

Shahbaz
quelle
1
Ich denke, das ist eine gute Frage. Teilen Sie es in zwei Teile und klären Sie Ihre Hauptfrage. "Kann ROS für Echtzeit verwendet werden?" oder 'Wird ROS in Echtzeit verwendet?' (2 verschiedene Fragen) sind von Ihrer Hauptfrage getrennt.
hauptmech
@hauptmech, na ja, ROS kann sicher nicht in Echtzeit verwendet werden, da es nicht ist!
Shahbaz
Ich bin mit @hauptmech einverstanden. Die Fragen sind verwirrend. Oben werden Sie gefragt, wie viele Personen / wie oft Echtzeitsysteme verwendet werden und später, wann / in welchem ​​Fall . Beides sind gute Fragen, also teilen Sie sie bitte in zwei oder reduzieren Sie sie auf eine. Vielen Dank!
Bit-Pirat
@bit-pirate, ich verstehe nicht warum du sagst, dass ich wann / in welchem ​​Fall gefragt habe . Ich habe so etwas nie gefragt. Wie ich schon sagte Die Frage ist, wie viel geneigt sind Entwickler Echtzeit - Anwendungen zu schreiben , wenn das Echtzeitverhalten tatsächlich benötigt wird? Mit anderen Worten, wie viel Prozent der Anwendungen , die tun Echtzeitverhalten erfordern, sind tatsächlich in Echtzeit umgesetzt? Ich persönlich weiß, wann und in welchem ​​Fall Echtzeitverhalten erforderlich ist, und habe diesbezüglich absolut keine Fragen. Tatsächlich bin ich überrascht, Antworten zu sehen, die das erklären .
Shahbaz
Danke für die Klarstellung! Für mich war der Titel verwirrend. Die IMO-Echtzeitprogrammierung + -Implementierung ist in der Robotik ausgereift, erfordert jedoch mehr Aufwand (Zeit, Geld, Fähigkeiten usw.), sodass die meisten Leute dies vermeiden, wenn dies nicht wirklich notwendig ist.
Bit-Pirat

Antworten:

10

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!

Mark Booth
quelle
Die Unterscheidung hier ist ziemlich relevant ... selbst in "realen" Low-Level-Systemen ist das Echtzeitbit ziemlich klein (basierend auf einem Timer-Tick-Interrupt), wohingegen der größte Teil des Systems nominal in Echtzeit ist (aber +) / - ein paar Nanosekunden hier und da ist erträglich). Ich lächle, wenn Leute über Echtzeitanwendungen sprechen, die auf WindowsCE oder Linux basieren ...
Andrew
1
Wie ich schon sagte @Andrew mit der richtigen Software, kann sogar Windows 7 mit einem RTX in Echtzeit erschwert werden . Sie sind sich nicht sicher, warum Sie Windows CE nicht für Echtzeit halten, da es eine deterministische Aufgabenplanung in Echtzeit bietet, da Version 2 und Linux mit einem Kernel wie RTLinux in Echtzeit ausgeführt werden können .
Mark Booth
Hi nochmal Mark (nicht sicher, wer hier wem nachstellt ...) - Ich stimme zu, dass Sie das können , aber die harte Erfahrung hat gezeigt, dass in vielen (? Den meisten?) Fällen Benutzer (Manager) die erforderlichen Add-Ons ignorieren und davon ausgehen dass das Vanille-System tun wird.
Andrew
@ Andrew - Meine Erfahrung mit RTX war, dass es einfach funktioniert hat . In den Pentium 4-Tagen musste man darauf achten, keine integrierten Grafiken oder Audiodaten zu verwenden, die den PCI-Bus überlasteten, aber das sollte heutzutage kein Problem sein.
Mark Booth
Es ist lange her, aber beim Zurücklesen dieser Seite, insbesondere in Bezug auf Fenster, möchte ich nur sagen, dass Sie nur einen Teil davon erwähnen, wie ein System in Echtzeit erstellt wird. Die Echtzeitplanung ist natürlich wichtig, aber es gibt viele Dinge, die Spitzen erzeugen können, die auch behandelt werden müssen, um ein System in Echtzeit zu erstellen. Interrupts sind das übliche Beispiel, SMI, Caches und Speicherbandbreite sind andere Beispiele. Nur weil es einen Echtzeitplaner gibt, wird das System nicht in Echtzeit ausgeführt.
Shahbaz
8

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:

PR2

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.

Raketenmagnet
quelle
Kurz gesagt, Sie sagen, dass Echtzeit oft nicht verwendet wird, weil Nicht-Echtzeit-Software "gut genug" funktioniert?
Shahbaz
@ Shahbaz - Ich kann nicht genau sagen, wie oft es tatsächlich verwendet wird, aber ich kann sagen, dass es unnötig sein kann, wenn es verwendet wird. Früher haben wir RTAI verwendet und es dann aufgegeben, weil es tatsächlich mehr hinderte als zu helfen.
Rocketmagnet
1
Ich möchte einen Punkt hervorheben: Sie haben so viel Rechenleistung auf dem PR2, dass Sie vielleicht etwas "Gutes" bekommen. Ich habe an einem Roboter mit "nur" einem Core2 Duo gearbeitet. Das ist dort keine Option: Der gesamte Stack beansprucht die meiste Zeit jeden Kern zu 100%. Hier waren Rock (Orocos) und RT-Linux notwendig, um den 1-kHz-Regelkreis zusammenzuhalten.
sylvain.joyeux
@ sylvain.joyeux - da stimme ich zu. Wenn Sie nur 2 Kerne haben, ist die Leistung von ROS für die Steuerung ziemlich schlecht.
Rocketmagnet
@Rocketmagnet Es tut mir leid, dass ich das hier runterstimmen muss, aber der PR2-Teil ist falsch. Auf dem PR2 gibt es eine einzelne Echtzeitschleife mit 1000 Hz parallel zum ROS (unter Linux + RT PREEMPT), die über Ethercat mit den Motorcontrollerkarten kommuniziert und die eigentliche Motorsteuerung für jeden DOF durchführt. Sie müssen beim Programmieren von Steuerungen (z. B. einer gemeinsamen Trajektoriensteuerung) vorsichtig sein, um nicht in Echtzeit zu brechen, und sie verfügen auch über spezielle Tools zum Verwalten (z. B. Laden / Entladen). Schauen Sie hier für weitere Details.
Bit-Pirat
4

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.

ronalchn
quelle
Danke für die Antwort. Vielleicht muss meine Frage besser formuliert werden, aber ich wollte nicht fragen, wann Echtzeit verwendet werden soll, sondern wie oft Menschen tatsächlich Echtzeit verwenden, wenn Echtzeit benötigt wird. Dennoch war Ihr Echtzeitverhalten auf Mikrocontrollern, ohne dass eine Echtzeitplattform erforderlich war, ein guter Punkt, den ich nicht in Betracht gezogen hatte.
Shahbaz
Nebenbei bemerkt sind Echtzeit und Schnell zwei orthogonale Konzepte. Wenn ein Pfadplaner innerhalb einer Minute genau entscheiden muss, handelt es sich um eine Echtzeitanwendung. Obwohl ich verstehe, warum Sie einen schnellen Roboter erwähnen würden.
Shahbaz
2

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.

Crake
quelle
2

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.

hauptmech
quelle
2

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.

Joe
quelle
2

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.

Jay Beavers
quelle
0

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. :-)

Bit-Pirat
quelle
0

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.

hauptmech
quelle
0

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

user3150208
quelle