Vicente Egea, Jorge Garrido, Roberto Guzmán, Ranko Zotovic Roberto Guzmán ist Informatiker (Physikalische Systeme), war Professor und Forscher im Bereich Robotik am Institut für Systeme und Automation der Polytechnischen Universität Valencia und Forscher am Fachbereich Informatik der Fernuniversität Hagen. Zur Zeit arbeitet er in der Entwicklungsabteilung bei TMC-Electronics. Ranko Zotovic ist Industrieingenieur. Er hat mehrere Jahre Erfahrung in der Konstruktion und der Einrichtung von Industriemaschinen wie Roboter und Maschinen für Schneidetechnik, für die Qualitätskontrolle usw. Er war in der Forschung tätig und ist zur Zeit Professor für Robotik und CAD/CAM am Institut für Systeme und Automation der Polytechnischen Universität Valencia. Jorge Garrido Serrano ist Informatiker (Physikalische Systeme). Seine Diplomarbeit, die den Entwurf und die Einrichtung der Softwarearchitektur des PCBot zum Inhalt hatte, wurde mit dem Bancaja-Preis für die Zusammenarbeit mit Unternehmen ausgezeichnet. Im Moment nimmt er als Forscher an dem europäischen Projekt "MobiNet" (Mobile Robotics Technology for Health Care Research Network) der Fernuniversität Hagen teil. Vicente Egea Mañas ist ebenfalls Informatiker auf dem Gebiet Physikalische Systeme. Er hat den Bancaja-Preis für die Zusammenarbeit mit Unternehmen für die Konstruktion und den Aufbau der Hardwarearchitektur des PCBot erhalten. Vor kurzem hat er seine berufliche Laufbahn bei der Firma TGI begonnen. Kontakt mit dem Autor Inhalt: Einführung Beschreibung des Fahrzeugs Softwarearchitektur Schlußwort

Ein selbstgesteuertes Fahrzeug auf der Basis von Linux

Zusammenfassung: Der Bereich der mobilen Robotik erlebte in den vergangenen Jahren ein gewaltiges Wachstum. Viele Institute für Robotik, Mechatronik und künstliche Intelligenz haben einen großen Teil ihrer Forschung auf selbstgesteuerte Fahrzeuge ausgerichtet. Bis jetzt haben hohe Entwicklungskosten ihren Einsatz auf die Raumfahrt, das Militär, Atomkraftwerke, usw. begeschränkt. Doch der erreichte Entwicklungsstand erlaubt jetzt ihre Anwendung in kommerziellen Bereichen wie Landwirtschaft, Industrie, Dienstleistungssektoren, Bergbau und Medizin. Es handelt sich um eine Schlüsseltechnologie, die ein spektakuläres Wachstumspotential beinhaltet .

Die momentan kommerziell erhältlichen selbstgesteuerten Fahrzeuge haben eine Reihe von Nachteilen, die ihre Anwendung in der Forschung einschränken. Hervorzuheben sind dabei ihr hoher Preis, proprietäre Architekturen, fehlende Dokumentation und die schwierige Skalierbarkeit, sowohl was die Hardware als auch die Software betrifft.

Um dieser Situation zu begegnen, entschied man sich am Institut für Systeme und Automation, ein selbstgesteuertes Fahrzeug zu bauen und dabei die Schwachstellen der kommerziellen Plattformen zu vermeiden. Man beschloß, eine auf einem PC basierende Architektur zu verwenden, aufgrund beträchtlicher Vorteile: Preis, Leistung, Kompatibilität, Skalierbarkeit, Verfügbarkeit von Software und Hardware. Der Einsatz von Linux und seiner Echtzeiterweiterung RT-Linux hat die Verwirklichung des Projektes enorm erleichtert.

Selbstgesteuertes Fahrzeug PCBot 1.0

Es handelt sich um ein holonomes Fahrzeug mit zwei angetriebenen Rädern und zwei Stützrädern. Das Bewegungsprinzip ist das gleiche wie das eines Rollstuhl oder eines Panzers, die Lenkung erfolgt durch die Kontrolle der Geschwindigkeit der einzelnen Räder.

Die Konstruktion wurde in zwei Bereiche aufgeteilt: im unteren Teil befinden sich alle mechanischen Elemente und die Stromversorgung, im oberen Teil die Elemente, die der Kontrolle und der Kommunikation dienen. Der untere Teil ist auf einer Aluminiumplatte befestigt. Dieses Niveau beinhaltet die Räder, das Getriebe, die Motoren, Aufzeichnungsgeräte, eine Leistungsstufe und die Batterien zur Stromversorgung. Der obere Teil ist auf dem Motherboard eines PCs aufgebaut und enthält eine Graphikkarte, eine Netzwerkkarte, eine Festplatte, eine Controllerkarte und ein Diskettenlaufwerk.

Vorder- und Seitenansicht des selbstgesteuerten Fahrzeugs PCBot

Die Hardwarearchitektur beruht auf einer Controllerkarte, die über eine der Leistungsstufen die Motoren steuert. Die Kontrolle der Achsen kann sowohl mit der Controllerkarte als auch direkt über den PC erfolgen. Die Entwicklung der Hardware und Software dieser Karte erfolgte im Rahmen dieses Projektes.

Hardwarearchitektur

Von einem externen Computer (host) werden Befehle an den PC des Fahrzeugs gesendet. Im Falle von Bewegungsbefehlen sendet der PC seinerseits Referenzen oder andere Befehle an die Controllerkarten. Diese erzeugen ein Spannungssignal, welches in den Leistungsstufen verstärkt wird und die Motoren mit Strom versorgt. Die Bewegung jeder Achse wird von einem Bewegungssensor (encoder) gemessen und das Meßsignal in den Controllerkarten digitalisiert.

Die Verwirklichung eines selbstgesteuerten Fahrzeugs erfordert auf der einen Seite ein Kontrollsystem mit einer geschlossenen Schleife, welches garantiert, daß in konstanten Zeitabständen Kontrollsignale gegeben werden. Auf der anderen Seite müssen bestimmte Zustandsvariablen regelmäßig aktualisiert werden, z. B. um die Position des Roboters zu jedem Zeitpunkt zu kennen.

Die zwei genannten Aspekte bedingen den Einsatz eines Echtzeitsystems. In einem Echtzeitsystem hängt das korrekte Systemverhalten nicht nur von den durchgeführten Berechnungen ab, sondern auch vom Zeitpunkt, an dem die Resultate erhalten werden.

Als Betriebssystem für die Softwarearchitektur wurde Linux (Kernel 2.0.33) mit der Echtzeiterweiterung RT-Linux (Version 0.6) gewählt.

Die Gründe für den Einsatz von Linux und RT-Linux sind die gleichen, die einige Automationsunternehmen dazu bewegen, ihre Software auf diesem System zu implementieren:

• Das Betriebssystem nutzt die Hardware des Gerätes optimal aus und ist sehr robust.
• Der Quellcode ist offen und deshalb einfach zu verändern und zu erweitern.
• Die Kosten in der Entwicklungsphase sind sehr gering, eigentlich null.
• Es verfügt über eine mächtige, kostenlose Echtzeiterweiterung, die in ihren Eigenschaften mit entsprechenden kommerziellen Systemen vergleichbar ist.
• Der technische Support ist durch eine Vielzahl von Enthusiasten ausgezeichnet.
• Es existiert eine umfangreiche Dokumentation in Form zahlreicher Webseiten.

Das Echtzeitsystem RT-Linux wurde am Department of Computer Science des New Mexico Mining and Technology Institute von Victor Yodaiken und Michael Barabanov entwickelt. Die Architektur ist in der folgenden Abbildung dargestellt. Der Echtzeitkernel läuft auf dem der Hardware nächsten Niveau. Ein Scheduler mit statischen Prioritäten verwaltet eine Reihe von Echtzeittasks mit vollständigem Zugriff auf die Hardware. Das eigentliche Linux wird von dem Scheduler als einer der Echtzeittasks angesehen, der die niedrigste Priorität hat und ausgeführt wird, wenn Zeit übrig ist.

Echtzeitsystem RT-Linux

Die Softwarearchitektur des PCBot beruht auf dem bekannten Client-Server-Modell. Eine Serveranwendung läuft auf dem Roboter und wartet auf Anfragen der Clientapplikationen, die auf anderen Maschinen laufen und über TCP/IP mit dem Server kommunizieren.

Die Verbindung mittels TCP/IP macht den Roboter von dem Betriebssystem unabhängig, unter dem die Host-Rechner laufen. Der Operator gibt über die Clientapplikationen die Befehle, die den Roboter steuern. Die Befehle sind von einem der drei Typen: Bewegung, Definition des Zustands oder Abfrage des Zustands. Die Clientapplikation kontrolliert die Syntax der übergebenen Befehle, erzeugt eine entsprechende Nachricht und übermittelt diese über Sockets an den Server.

Der Server selbst wartet permanent auf Verbindungen mit einem Client. Wenn einmal eine Verbindung zustande gekommen ist, dient der Server als Vermittler für den Austausch von Nachrichten zwischen der Clientapplikation und dem Echtzeitmodul, das die Kontrolltasks ausführt.

Das Echtzeitmodul hat die Aufgabe, die Befehle auszuführen, die der Roboter erhält, seien es solche zur Bewegungssteuerung, zur Definition des Zustands oder zur Abfrage des Zustandes. Außerdem übernimmt es die Überwachung der Integrität des Systems mittels eines Tasks vom Typ Watchdog.

Softwarearchitektur

Die Architektur ist in zwei Teile aufgeteilt, einen, der unter Linux läuft und einen, dessen zeitliche Anforderungen in Echtzeit von RT-Linux ausgeführt werden. Der Server befindet sich in dem Teil, der unter Linux läuft, auf dem PC, der auf dem Fahrzeug installiert ist. Der Client ist eine andere Anwendung ohne zeitliche Anforderungen und muß nicht unbedingt auf dem PC des Roboters laufen.

Das Echtzeitmodul setzt sich aus mehreren periodischen (Bewegungsanweisungen und Watchdog) und sporadischen (Treiber und Stop) Echtzeittasks zusammen.

Der Zugriff der Echtzeittasks auf die Hardware wird durch eine Binärsemaphore geschützt. Es gibt mehrere Gründe für die Verwendung dieser Semaphore. Erstens basiert das Protokoll der Kommunikation mit den Controllern auf einem Verschiebungsregister. Eine Unterbrechung durch einen anderen Task führt dazu, daß Informationen falsch in den Registern ankommen. Zweitens gibt es auch Protokolle auf dem Niveau der Register, die nicht unterbrochen werden dürfen und schließlich müssen Kontrollsignale oder Bewegungsanweisungen auf beide Achsen mit größtmöglicher zeitlicher Übereinstimmung gesendet werden.

Die Kommunikation zwischen dem Echtzeitmodul und dem Server geschieht über drei RT-FIFO-Stapel. In einen von ihnen schreibt der Server die Bewegungsanweisungen, die vom Client kommen. Das Echtzeitmodul benutzt die beiden anderen Stapel, um dem Server die Annahme der gesendeten Befehle und dem Client über den Server kritische Situationen zu melden.

Eine Operationssequenz sieht folgendermaßen aus: der Operateur startet einen Clientprozeß, dessen Aufgabe es ist, eine Schnittstelle zwischen dem Operateur und dem PCBot zu bilden. Der Client verarbeitet die Befehle und übergibt sie dem Server, der sie aufbereitet, um sie über den RT-FIFO-Stapel weiter an das Echtzeitmodul zu senden.

Ein dem RT-FIFO zugewiesener Treiberprozeß nimmt die Anweisung auf, und wenn sie die Bewegung betrifft, startet er den entsprechenden Echtzeittask und sendet eine Bestätigungsmeldung an den Server. Dieser Task führt an der Hardware die notwendigen Aktionen aus, um die Motoren zu betätigen.

Falls es keine Bewegungsanweisung ist, handelt es sich um einen Definitionsbefehl oder eine Zustandsabfrage. In diesem Fall antwortet derselbe Prozeß auf die Anfrage und schreibt bzw. liest die entsprechenden globalen Variablen.

Die globalen Variablen befinden sich in einem Speicherbereich, den sich die Echtzeittasks und der Treiber teilen. Sie dienen als Kommunikationsmittel zwischen diesen Tasks. Der Watchdog kümmert sich u. a. darum, dem Server wichtige Zustandsveränderungen wie auch mögliche außergewöhnliche Situationen zu melden.

Softwarearchitektur - Systemtasks

Die auf einem PC basierende Architektur bringt eine Reihe von Vorteilen wie der niedrige Preis, die einfache Erweiterungsmöglichkeit sowohl der Hardware als auch der Software, die Flexibilität aufgrund der großen Anzahl der verfügbaren Softwarepakete und die Leistung in Bezug auf die Rechenkapazität. Zudem wird die Hardware nie obsolet, denn sie wird schnell durch eine neue Generation ersetzt, wobei die Kompatibilität mit der Software erhalten bleibt.

Die Wahl von Linux zusammen mit seiner Echtzeiterweiterung RT-Linux hat sich als sehr geschickt erwiesen. Es wurden sehr leistungsfähige Entwicklungstools wie die GNU-Umgebung wpe (Windows Programming Environment) oder der GNU-C-Compiler verwendet, und das alles kostenlos.

Das System hat nicht nur seine Robustheit in der Praxis unter Beweis gestellt, sondern nutzt die Ressourcen der Maschine optimal aus, so daß als Bordcomputer ein 486er eingesetzt werden konnte, ohne Einbußen in Bezug auf die Rechenleistung oder die Entwicklungszeit (mehrere User gleichzeitig auf diesem Rechner) zu erleiden. Tatsächlich zeigten die Analysen, daß auch im schlimmsten Fall immer noch 70 % der Prozessorzeit zur Verfügung standen.

Die gesamte Software, die verwendet wurde, ist Public Domain, so daß die Quellen jederzeit zugänglich waren. Dies erlaubte ein detailliertes Verständnis des Echtzeitsystems und öffnete neue Erweiterungsmöglichkeiten für die Zukunft (Einsatz anderer Scheduler, Treiberentwicklung im Echtzeitbereich usw.), die mit kommerziellen Fahrzeugen undenkbar wären.

RT-Linux läßt sich einfach in Echtzeit debuggen unter Verwendung verschiedener Mechanismen, die von der Modifikation des Kernels bis zur Speicherung und Visualisierung der Variablen durch Aufruf des Systembefehls printk reichen.

Bei dem Großteil der Probleme, die während der Entwicklungszeit aufgetreten sind, konnte man sich auf die Unterstützung der Mitglieder der RT-Linux-Mailingliste und auf die relativ ausführliche Dokumentation verlassen.

http://www.rtlinux.org

Weitere Artikel über RT-Linux im LinuxFocus:
Real-Time Linux
Real-Time Linux II

Original auf Spanisch

Übersetzung von Thomas Kappes

mirror server hosted at Truenetwork, Russian Federation.