Ich bin zurück an einem Computer!
Wie ich in diesem Kommentar sagte , ist ROS im Allgemeinen nicht obligatorisch. ROS ist eine Plattform unter vielen, berühmt vor allem, weil Willow Garage irgendwann kostenlose Roboter an diejenigen verschenkt, die die meisten ROS-Module geschrieben haben. Das heißt, es ist nicht die bestmögliche Plattform und sicherlich nichts Besonderes. Insbesondere der Wettbewerb führte zu vielen Modulen von geringer Qualität, nur um die Zahlen zu erhöhen.
Im Laufe der Zeit hat sich die Qualität der ROS-Module verbessert, und es gibt auch viele davon. Mit ROS haben Sie daher den Vorteil, dass Sie viel von dem, was bereits getan wurde, wiederverwenden können. Sie können hier einige Gründe lesen , warum Sie ROS verwenden möchten.
In diesem Sinne sollten Sie auch auf die Nebenwirkungen achten.
Verteilte Kontrolle
Mit ROS haben Sie viele Knoten, die über das Netzwerk miteinander kommunizieren. Dies ist manchmal gut und einfach, führt jedoch im Allgemeinen zu einer stark variierenden Verzögerung beim Empfang von Nachrichten. Infolgedessen müssten Sie eine große Steuerungsverzögerung haben, um sicherzustellen, dass alle Nachrichten eintreffen. Dies bedeutet, dass Sie nicht schnell auf Ereignisse reagieren können, was wiederum bedeutet, dass Sie Ihren Roboter langsamer bewegen müssen, um diese Ereignisse nicht zu verpassen.
Ob Sie es glauben oder nicht, die Leute steuern den Roboter tatsächlich über ROS ( MoveIt! Ist der Name des relevanten Satzes von Komponenten). Schleppend. Unsicher. Aber einfach!
Nicht in Echtzeit
Auch wenn ROS nicht verteilt ist, ist es keine Echtzeitplattform. Das bedeutet, dass es im freien Ermessen des Linux-Kernels liegt, Ihre Aufgaben jederzeit nach eigenem Ermessen zu planen. Dies ist für einige Anwendungen in Ordnung, für andere jedoch nicht. Sie müssen sich also Ihre eigenen Anforderungen ansehen. Benötigen Sie eine Garantie dafür, dass Ihre Aufgabe innerhalb eines bekannten Zeitrahmens abgeschlossen wird? In diesem Fall benötigen Sie ein Echtzeitsystem.
Gehostete Laufzeitumgebung
Ein weiterer zu berücksichtigender Punkt ist, dass ROS zwar ein allgemeines Kommunikationsprotokoll ist, jedoch im Wesentlichen nur für gehostete Umgebungen unterstützt wird. Gehostet bedeutet, dass der Code auf einem Kernel ausgeführt wird, im Gegensatz zu freistehend, was bedeutet, dass der Code die Hardware direkt steuert (z. B. auf einem Mikrocontroller).
Wenn Ihre Robotikanwendung in der Nähe der Hardware ausgeführt wird und Sie daher ein Programm benötigen, das auf einem Mikrocontroller ausgeführt wird, hilft Ihnen ROS nicht weiter.
Plattformverriegelung
Last but not least führt die Entwicklung für ROS zu einer Plattformsperre. Dies bedeutet, dass wenn Sie sich in Zukunft aus dem einen oder anderen Grund dazu entschließen, Ihre Arbeit auf eine andere Roboterplattform wie OROCOS, YARP usw. zu stützen, dies unerträglich wäre.
Sie wären auch etwas an Linux gebunden. Linux ist zweifellos das Beste, aber eines Tages müssen Sie möglicherweise ein anderes System wie QNX, VxWorks usw. unterstützen, und Sie würden dort auch Probleme haben.
Wenn Sie für Mikrocontroller schreiben, vergessen Sie ROS. Wenn Sie High-Level-Module schreiben, empfehle ich dringend, tragbaren Code zu schreiben. Angenommen, Sie haben einen neuen Sensor entwickelt und möchten ein Modul schreiben, das Daten von diesem Sensor erfasst, der über den CAN-Bus mit Ihrem Computer verbunden ist.
In dieser Situation können Sie eine unabhängige Bibliothek mit Funktionen schreiben, die mit Ihrem Sensor arbeiten und Daten erfassen können. Sie könnten sogar daran denken, einen Thread in der Bibliothek zu erzeugen, der regelmäßig Daten erfasst und in die Warteschlange stellt.
Sobald Sie über diese Hilfsbibliothek verfügen, können Sie eine CLI, eine GUI, ein ROS-Modul, ein OROCOS-Modul, ein YARP-Modul schreiben, eine Verbindung zu Matlab herstellen oder was auch immer Sie für die Interaktion mit Ihrem Sensor verwenden möchten.
Schlussbemerkung: Was ich hier gesagt habe, gilt allgemein für alle Robotikplattformen und nicht nur für ROS.