Wir sind Studenten, die einen mittelgroßen (~ 4,5 Fuß großen) humanoiden Roboter als gesponsertes Forschungsprojekt in der Schule entwickeln. Zu den wichtigsten Aufgaben, die der Roboter ausführen kann, gehören: Umherbewegen (vorwärts, rückwärts, seitwärts), Laufen, Aufnehmen von Objekten. Wir überlegen, ein hard Echtzeit-Betriebssystem zu verwenden, um den Roboter zu steuern. Da wir in diesem Bereich jedoch praktisch keine Erfahrung mit eingebetteten Systemen oder Betriebssystemen haben und eine breite Palette von Optionen zur Verfügung steht, sind wir uns nicht sicher, welche davon geeignet wäre. Wir haben folgendes gefunden (in Klammern ist unser aktueller Eindruck von ihnen):
Ich habe eine Reihe von Fragen:
UPDATE: Vielen Dank für Ihre unglaublich detaillierten Antworten. Es ist klar, dass wir das falsch machen. Tauchen ohne Wissen und Vauge Anforderungen wäre sicherlich schlecht. Wir müssen uns hinsetzen und genau ausmalen, was wir brauchen. Wenn wir damit weit genug voraus sind, werden wir versuchen, ein geeignetes Betriebssystem zu finden. Mal sehen, wie das geht. Ich werde auch Kapitel 2 von MicroC OS II: Der Echtzeit-Kernel lesen.
Ihre Wahl des Betriebssystems wird von der "humanoiden Roboter" -Einschränkung bestimmt, es gibt kein spezifisches "humanoides Roboter-Betriebssystem", und sicherlich würde kein Betriebssystem dafür bestimmt sein, wie groß solch ein Roboter ist! ;-)! Die kritischen Faktoren sind
Andere Faktoren können wichtig sein wie:
, obwohl diese in vielen Fällen nicht notwendigerweise ein wesentlicher Teil des Betriebssystems sein müssen, da plattformunabhängige Plattformen von Drittanbietern in vielen Fällen verfügbar sind. Wo Sie diese benötigen, kann die Integration mit dem Betriebssystem jedoch hilfreich sein sich mit Thread-Sicherheit und Ressourcen-Sperrung beschäftigen.
Keine der von Ihnen vorgeschlagenen Optionen würde wahrscheinlich in meine Liste aufgenommen.
Alles, was auf Linux basiert, wird eine MMU benötigen (es sei denn, man benutzt uCLinux oder seine Derivate, aber die MMU-Unterstützung ist einer der wenigen guten Gründe für die Verwendung von Linux in einem eingebetteten System). Linux ist nicht als Echtzeit-Betriebssystem gedacht und jede Echtzeit-Unterstützung ist ein Nachdenken und wird selten so deterministisch sein wie ein echtes Echtzeit-Betriebssystem. Jedes Linux benötigt zum Aufstarten ebenfalls erhebliche Speicherressourcen, erwartet mindestens 4 MB RAM für alles Nutzbare, während RTOS-Kernel wie FreeRTOS und uC / OS-II nur etwa 4 KB benötigen - hier vergleicht man Kreide mit Käse. Das heißt, sie haben nicht den Nutzen eines Linux-basierten Betriebssystems wie Dateisysteme oder Netzwerkunterstützung (obwohl diese als eigenständige Bibliotheken hinzugefügt werden können).
Wenn Sie die Funktionen Motion Control und Sensor / Aktor auf demselben Prozessor wie Ihre kognitiven Funktionen ausführen wollen, brauchen Sie bestimmt ein deterministisches RTOS. Wenn die Plattform jedoch ein verteiltes System mit separaten Prozessoren ist, die sich mit Bewegungssteuerung und anderen Echtzeit-Sensor- / Aktuator-E / A befassen, dann können Sie mit einem einfachen RTOS-Kernel oder gar keinem Betriebssystem in den E / A-Prozessoren auskommen (das können dann auch kleinere, weniger leistungsfähige Prozessoren sein) und ein GPOS im kognitiven (Entscheidungsfindung und Planung) Prozessor.
Ich habe FreeRTOS kürzlich bewertet, es ist minimalistisch, einfach und klein und bietet nur die grundlegenden Threading-, Timing- und IPC-Mechanismen und wenig anderes. Es funktioniert, aber auch viele andere attraktivere Optionen, sowohl kommerzielle als auch nichtkommerzielle. Ich habe es mit Keils RTX-Kernel (in der MDK-ARM-Tool-Suite enthalten) und dem Werbespot
uC / OS-II ist gut entworfen und dokumentiert (in Jean Labrosses Buch) und es ist großartig, wenn Sie sehen wollten, wie ein RTOS funktioniert. Sein größter Fehler ist sein sehr restriktives Prioritäts-Scheduling-Schema, das für sehr kleine Ziele effizient ist, aber möglicherweise nicht so flexibel wie Sie möchten. Jedem Thread muss eine bestimmte Prioritätsstufe zugewiesen werden, sodass er keine Round-Robin-Planung unterstützt, was für Nicht-Echtzeit-Hintergrundaufgaben nützlich ist. uC / OS-III behebt dieses Manko, aber auch viele andere Optionen.
Wenn Ihr Zielprozessor über eine MMU verfügt, empfehle ich dringend die Verwendung eines Betriebssystems, das es so unterstützt, dass jeder Thread oder Prozess vor jedem anderen geschützt ist. Das System wird viel robuster und leichter zu debuggen sein, besonders wenn als Team entwickelt. In einem solchen Betriebssystem verursacht eine fehlerhafte Aufgabe, die andernfalls auf den Ressourcen eines anderen Threads mit nichtdeterministischen und im Allgemeinen schwer zu debuggenden Ergebnissen stampfen würde, stattdessen eine Ausnahme und stoppt genau dort, wo der Fehler aufgetreten ist, anstatt vielleicht irgendwann später, wenn die beschädigten Daten ankommen verwendet.
Sie müssen sich wahrscheinlich nicht auf ein kostenloses oder Open-Source-RTOS beschränken, viele Anbieter erlauben die kostenlose Nutzung für Bildung und Evaluierung. Ich würde Ihnen wärmstens empfehlen, dass Sie QNX Neutrino in Betracht ziehen, es ist frei für nichtkommerzielle und akademische Zwecke , und verfügt über die robusteste MMU-Unterstützung, die in jedem RTOS verfügbar ist, und alle Entwicklungswerkzeuge, die Sie benötigen die Eclipse-basierte Momentics-IDE ist enthalten. Es ist mehr als nur ein scheduling Kernel, einschließlich der Unterstützung für alle Dienste, die Sie von einem vollständigen Betriebssystem erwarten würden.Es läuft auf ARM, x86, SH-4 PowerPC und MIPS Architekturen. Das Ausführen auf x86 ist besonders nützlich, da es bedeutet, dass Sie es testen und auswerten und sogar einen Großteil Ihres Codes in einer virtuellen Maschine entwickeln können auf Ihrem Desktop .
Eine weitere Alternative, die echte hard-realtime ist, während OS-Dienste über die bloße Planung und IPC hinaus unterstützt werden, sind eCos . Es hat eine native, POSIX- und uITRON-API, Standardtreiber für CAN, ADC, SPI, I2C, FLASH, PCI, Seriell, Filesystems, USB und PCI und mehr und beinhaltet TCP / IP-Netzwerkunterstützung. Es ist ein vollständiges Betriebssystem in diesem Sinne, aber im Gegensatz zu Linux ist es nicht monolithisch; Es ist skalierbar und statisch mit Ihrem Anwendungscode verknüpft, sodass Funktionen, die Sie nicht verwenden, nicht in der Laufzeit-Binärdatei enthalten sind. Es läuft auf ARM, CalmRISC, Cortex-M, FR-V, FR30, H8, IA32, 68K / ColdFire, Matsushita AM3x, MIPS, NEC V8xx, PowerPC, SPARC und SuperH. Theoretisch könnte man den IA32 (x86) -Port auf einer VM auf einem PC zum Testen und Entwickeln von High-Level-Code ausführen, obwohl man das im Gegensatz zu QNXs Out-of-the-Box-Evaluierung selbst erledigen müsste.
Hinzugefügt bezüglich:
Wir haben sehr wenig Ahnung von Betriebssystemen im Allgemeinen. Müssen wir zuerst etwas über sie erfahren? Wenn ja, was ist eine gute, kurze Einführung in das Thema?
Dies ist dann vielleicht nicht die Zeit, um mit dem Erlernen von Linux zu beginnen (obwohl es die Vorteile weitgehender Vertrautheit und Community-Unterstützung bietet, hat es eine Menge Dinge, die Sie nicht brauchen werden und viele verfügbare Support-Ressourcen werden nicht bekannt sein Echtzeit-Steuerungssysteme Anwendungen.
Kapitel 2 von Labrosses UC / OS-II-Buch gibt einen allgemeinen Überblick über RTOS-Konzepte wie Planung, Synchronisierung und IPC, die für die meisten RTOS und nicht nur für uC / OS-II gelten. Ähnliches Material wird in Jack Ganssles jüngstem RTOS vorgestellt Fundamentals Kurs auf EETimes (es ist vielleicht ähnlich, weil es von Mircium gesponsert wird und uC / OS-II als Fallstudie verwendet, aber es ist in den meisten Fällen ähnlich allgemein).
Meine Lösung für einen schnellen Einstieg in ein beliebiges Fach ist, das Thema mit "101" zu versehen (eine allgemeine Einführungsnummer in der Wissenschaft). "RTOS 101" wird Ihnen einige Startpunkte von zugegebenermaßen unterschiedlicher Qualität liefern - überprüfen Sie die Seriösität der Quelle, Wenn es eine Firma ist, können sie ein bestimmtes Produkt verkaufen, wenn es ein Hobbyist ist, haben sie vielleicht ein paar Einsichten, aber vielleicht eine enge Sichtweise (oft in Bezug auf bestimmte Lieblingshardware), und haben vielleicht nicht die Strenge einer wissenschaftlichen Arbeit .
Zu CONFIG_PREMPT_RT hinzugefügt:
Es macht Linux nicht zu einem harten Echtzeit-Betriebssystem. Es kann für einige Anwendungen geeignet sein. Wenn Sie eine PID-Bewegungssteuerung durchführen (anstatt einen dedizierten Controller oder einen separaten Prozessor zu verwenden), oder irgendeine Art von Rückkopplungssteuerung mit geschlossenem Regelkreis, wird dieser Patch meiner Meinung nach zumindest nicht zuverlässig funktionieren. Ich habe das gefunden: Ein Vergleich von Echtzeit-Linux-Ansätzen . Es behandelt eine Reihe von Ansätzen zur Verwendung von Linux in Echtzeitanwendungen, einschließlich CONFIG_PREMPT_RT. Es wird ausführlich in Teil C diskutiert.
Dies beantwortet nicht die spezifische Frage, aber:
Bevor Sie nach einem bestimmten Betriebssystem fragen, benötigen Sie viel mehr Details über die Architektur und die Einschränkungen.
Ich würde mit der I / O beginnen:
Nun, da Sie wissen, was Sie kontrollieren müssen und wie schnell, wie kontrollieren Sie es?
An dieser Stelle können Sie beginnen, bestimmte Prozessoren und Architekturen zu betrachten. Erst nachdem Sie es auf ein oder zwei gute Optionen eingeschränkt haben, sollten Sie anfangen, das Betriebssystem zu betrachten.
Ich erwarte, dass Sie am Ende ein hartes Echtzeit-Betriebssystem für die Bewegungssteuerungsaspekte eines laufenden Roboters benötigen werden.
Es ist möglicherweise nicht notwendig, Linux in Echtzeit auszuführen. Bei einem 4,5 Fuß großen Humanoid mit einem CM von sagen wir 3 Fuß, kann Ihre Kontrollschleife bei 20 Hz laufen und Sie können immer noch Ihre IMU-Signale verdauen und verhindern, dass das Ding fällt. Ein normales Embedded-Linux, das keinen Counterstrike-Game-Server parallel zur Steuerung der Roboter-Motoren betreibt, bietet Ihnen eine zuverlässige Event-Handhabung von mindestens 50Hz, sogar ohne den Steuerungsprozess des Roboters "nett" zu gestalten. (vorausgesetzt, Sie werden Ihr Linux auf einem RoBoard oder einem FitPC ausführen). In jedem Fall ist es wahrscheinlich einfacher, von einem verpassten Frame als von RT Linux zu erholen. Den Kernel so laufen zu lassen, dass er Ihre Handler bei einer Unterbrechung innerhalb von X Mikrosekunden (dh Echtzeit) zuverlässig aufruft, beinhaltet etwas, was von manchen als nicht-trivial und mit einigen Nebenwirkungen betrachtet wird.
Vielleicht ist es besser, wenn Sie eine andere Mikroprozessorplatine haben, die mit den Motoren / Servos kommuniziert und die verdauten Informationen an Linux weiterleitet.
In unserem Projekt ActuatedCharacter.com gelang es uns, einen Regelkreis zwischen einem RoBoard.com Linux und 20 (Dynamixel) Servos (mit eigener Firmware) über 200Hz mit einer FTDI-Schnittstelle zu den Servos und ohne Echtzeitkernel zu bekommen Änderungen. Wenn Sie Dynamix-Servos als Aktuatoren einsetzen, finden Sie in den robosavvy.com-Foren allgemeine Informationen zum Aufbau von humanoiden Robotern (für Robocup oder für allgemeine Forschung), alternative Firmware für bessere Regelungsraten, Probleme mit FTDI-Latenz, seriell gesteuerte Servos . Berücksichtigen Sie auch das zu entwickelnde Software-Framework, das Ihnen bei Ihren Anforderungen hilft. Offensichtlich sprechen wir mit etablierten Robocup-Teams der humanoiden Liga, aber auch von Interesse sind Inriaflowers, NAO / Aldebaran und natürlich ROS.