Software Entwurf für den RCX von Lego Mindstorms

1. Software Entwurf für den RCX von Lego Mindstorms

2. Gliederung • Einleitung • Was ist ECRobot? • Beteiligte Komponenten zum Entwurf mit ECRobot • Simulink • S-Funktionen • Real-Time-Workshop • Stateflow • ECRobot • Praktische Erfahrungen • Bewertung

3. Einleitung • Das Ziel des HS war die Suche nach einem Entwicklungstool für den RCX das auf möglichst hohem Abstraktionsniveau arbeitet. • Die Webrecherche erbrachte dabei 2 Kandidaten: • Robolab • ECRobot • Robolab ist jedoch kostenpflichtig und es stand nur eine Demo zur Verfügung. • Deshalb wurde mit ECRobot weiter gearbeitet.

4. Was ist ECRobot? • ECRobot ist eine Erweiterungs- Komponente für Matlab. • Es bringt zusätzlich ein: • Blockbibliothek für Lego in Simulink • Target für den Real-Time-Workshop • Makefiles zur Einbindung der Hilfskomponenten

5. Beteiligte Komponenten zum Entwurf mit ECRobot • Neben den in Matlab bereits enthaltenen Komponenten wie Simulink und dem Real-Time-Workshop sind noch etliche unabhängige Komponenten beteiligt: • gMake • Cygnus • gcc-Compiler • Dll • LegOs

6. Beteiligte Komponenten zum Entwurf mit ECRobot Komponentenüberblick

7. Simulink • Simulink ist ein Software Packet zum Modellieren, Simulieren und Analysieren dynamischer Systeme. • einige Features: • graphische Benutzeroberfläche zum Modellieren • Modelle als Blockdiagramm per Click-and-Drop zusammenbauen • Abschirmung des Nutzers vor der den Blöcken innewohnenden Funktionalität (Code)

8. Simulink • Bei der Modellsimulation können die Zustände und Ergebnisse problemlos mit der vollen Matlab Funktionalität ausgewertet werden. • Simulationen können kontinuierlich durchlaufen werden oder auch im Schrittbetrieb Takt für Takt zum debuggen des Modells

9. Simulink • Erläuterung wichtiger Elemente: • Blockdiagramm • Block • Blockparameter • Sample Time • Subsysteme • Selbst erstellte Blöcke • Signale • Bibliotheken • bedingt ausgeführte Subblöcke

10. Simulink • Block Diagramm:Ein Block Diagramm ist ein bildliches Modell eines dynamischen Systems. Es besteht aus einer Reihe von Symbolen, Blöcke genannt, verbunden durch Linien die Signale repräsentieren. Jeder Block repräsentiert ein elementares dynamisches System das eine kontinuierliche/diskrete Ausgabe erzeugt. Die Linien repräsentieren Verbindungen von Blockeingängen zu Blockausgängen. Der Typ eines Blocks bestimmt die Beziehung zwischen Ein- und Ausgängen.

11. Simulink • Blöcke:Blöcke repräsentieren elementare dynamische Systeme, die durch Simulink simuliert werden können. Ein Block beinhaltet einen oder mehrere Sätze von Eingaben, Zuständen und Ausgaben. Der Blockausgang ist bestimmt durch eine Funktion abhängig von Eingängen, Zuständen und Zeit.

12. Simulink • Block Parameter:Die Schlüsseleigenschaften von vielen Standardblöcken sind parametrisiert um möglichst flexible Aufgabenlösung zu gewährleisten. Jeder parametrisierbare Block hat einen Block Dialog in dem die Parameter geändert werden können. Wenn Parameter als ‚tunable’ angelegt so können sie auch während einer Simulation geändert werden.

13. Simulink • Sample Time:Die Sample Time muss bei diskreten Blöcken so eingestellt werden das verbundene Blöcke dieselbe besitzen. Was genau mit Sample Time gemeint ist wird später noch genauer beleuchtet.

14. Simulink • Signale: • Als Signale werden die Blockausgänge bezeichnet • beinhaltend Datentyp (z.B. 8 – bit), Zahlentyp (integer, real oder komplex) und Dimensionalität (Arraygröße) • Die meisten Blöcke sind jedoch in den Eingangs- und Ausgangssignalen eingeschränkt

15. Simulink • Bibliotheken: • die Blöcke aus den Bibliotheken können in die Modelle kopiert werden • Dabei bleiben sie verbunden, weswegen Änderungen des Bibliotheksblockes auch auf den Modellblock wirken • Die Modellblöcke können von der Bibliothek entkoppelt werden

16. Simulink • Subsysteme: • ermöglichen komplexe Systeme hierarchisch zu ordnen • beliebig tief gestaffelt • repräsentiert durch Subsystemblock • festlegen von Ein- und Ausgängen • Anlegen des Subblockdiagramms wie Blockdiagramm

17. Simulink • Selbsterstellte Blöcke: • Es besteht die Möglichkeit eigene Blöcke zu erstellen. • Graphisch oder über Programmierung • können in Blockbibliotheken übernommen werden • Unterschied zu Subsystemen, beim grafischen Erstellen, ist der Parameterdialog • die Programmierung wird im Kapitel S-Funktionen genauer erläutert

18. Simulink • bedingt ausführbare Subblöcke: • die Ausführung ist von einem Kontrollsignal abhängig • Reaktion auf Signalflanken oder -werte

19. S-Funktionen • sind eine Möglichkeit Code in sein Projekt zu integrieren • der Vorteil ist das einmal programmierte Blöcke leicht wieder verwendbar sind • vor allem durch die Möglichkeit des Parametrisierung • unterstützt werden dafür etliche Programmiersprachen wie C, C++, Ada oder Fortran • es gibt prinzipiell 2 Arten S-Funktionen zu schreiben, als: • M-File, auf der Matlab-Sprache basiert (einfacher) • Mex-File, für die normalen Programmiersprachen (ausdrucksstärker)

20. S-Funktionen • Betrachtungsweise eines Simulinkblockes, an der auch der Aufbau der S-Funktionen festgemacht ist:

21. S-Funktionen • Dargestellt sind die einzelnen Module der S-Funktion die bei einem Simulationsschritt ausgeführt werden.

22. S-Funktionen • so genannte Call-Back-Methoden repräsentieren die einzelnen Module wie sie im letzten Bild dargestellt wurden • Für die S-Funktionen werden Schablonen bereitgestellt in denen die Call-Back-Methoden „nur noch“ mit Inhalt gefüllt werden müssen.

23. Real-Time-Workshop • erzeugt Programme von Simulink-Entwürfen zum Prototypen, Testen und Einsetzen, von Real-Time Systemen, auf einer Vielzahl von Ziel-Plattformen • er kann direkt Source Code generieren, der den Compiler enthält, Input und Output Geräte, Speicher-Modelle, Kommunikationsknoten und andere Charakteristiken die eine Applikation möglicherweise fordert

24. Real-Time-Workshop • Für uns wichtige Fähigkeiten und Features des RTW sind: • Simulink Code Generator: generiert automatisch C-Code aus dem Simulink-Modell • Make Process: der erweiterbare make Prozess ermöglicht es ein eigenes Produktions oder Rapid Prototyping Target zu kreieren

25. Real-Time-Workshop • der generierte Code ist Prozessor unabhängig • er repräsentiert das Modell exakt • effizienter Code für S-Funktionen kann erzeugt werden durch Nutzung der Target Language Compiler Instruktionen (TLC Scripts genannt) und kann automatisch, mit generierten Code, integriert werden • unterstützt werden folgende Compiler: • unter Windows die Compiler von Borland, LCC, Microsoft Visual C/C++ und Watcom • unter Linux ist als Default der cc eingestellt, der gcc wird ebenfalls unterstützt.

26. Real-Time-Workshop • Entwicklungsdiagramm für Entwurfsprozess

27. Stateflow • ist ein graphisches Design und Entwicklungstool zur Simulation komplexer reaktiver Systeme basierend auf der finiten Zustandsmaschinen Theorie • mit dem Stateflow modelliert man den Teil des Modells der auf Ereignisse reagieren soll

28. ECRobot • Das ECRobot Target wurde hauptsächlich durch das modifizieren von Code und Control Files, die der Real-Time-Workshop bereits mitbringt, erstellt. • diese Files fallen in 2 Kategorien: • Das Run-Time-Interface besteht aus Code der die Ausführung von generiertem Modell Code überwacht und unterstützt. Im ECRobot Target, beinhaltet das Run-Time Interface das Haupt Programm, eingebundene Geräte Treiber und Header Files die die Anbindung an den LegOS Kernel gewährleisten. • Control Files. Die Code Generierung und der Build Prozess werden gesteuert durch ein angepasstes System Target Files und Template Makefiles. Die angepassten Kontroll-Files starten einen Target spezifischen Cross-Compiler und (optional) downloaden das generierte Programm ins Zielsystem.

29. ECRobot • das Betriebssystem das auf dem RCX laufen muss heißt LegOS • der verwendete Compiler ist der GCC Cross-Compiler für den Hitachi h8300 Mikrocontroller • zum Übertragen des LegOS und der Programme auf den RCX kommt das Tool Dll zum Einsatz • da für einige der Zusatzkomponenten eine Unix-Umgebung notwendig ist kommt noch das Tool Cygnus zum Einsatz, das diese emuliert • die auf dieser Seite genannten Zusatztools sind alle unabhängig vom ECRobot und frei erhältlich

30. ECRobot • die ECRobot Geräte-Treiber-Blöcke sind in einer Bibliothek gesammelt (ECRobot.mdl)

31. ECRobot • Das Template Makefile für das ECRobot Target ist ECRobot.tmf. Es ist eine angepasste Version des ert_unix.tmf. • Die wichtigsten Anpassungen sind: • Der Build Prozess ruft gmake auf, ein Make Utility das mit dem Real-Time-Workshop installiert wird. • Das generierte Makefile startet den GCC Cross-Compiler für den Hitachi h8300 Mikrocontroller und spezifiziert Kommandozeilenparameter für den Compiler. • Das generierte Modellfile hat den Namen model.lx. Optionell, wird der generierte Code in den RCX herunter geladen via dem dll-Utility

32. ECRobot

33. Praktische Erfahrungen • im praktischen Einsatz sind einige Hindernisse aufgetreten: • das erste große Hinderniss ist die Installation: • Offiziell dokumentiert sind von Mathworks 2 Arten der Installation von ECRobot. • einmal eine von Hand Installation • und als zweites ein Script zur automatischen Einrichtung • Trotz intensiver Bemühungen waren beide Versionen nicht zum funktionieren zu bringen.

34. Praktische Erfahrungen • Die letztendlich eingesetzte Version, mit der das ECRobot getestet wurde, ist eine fertig integrierte Version die freundlichwerweise einer der Entwickler von Mathworks zur Verfügung stellte. • Ursache der Installations-Probleme sind meiner Meinung nach massive Versionskonflikte verursacht durch die vielen verschiedenen Komponenten die unabhängig voneinander entwickelt werden. • Den Umfang den die Einrichtung von ECRobot hat spiegelt wohl am besten die Tatsache wieder, dass das automatische Script etwa eine halbe Stunde zur Installation benötigen soll.

35. Praktische Erfahrungen • das zweite Hindernis ist die, etwas größer als angenommene, Entwicklungskomplexität: • Bei der Modellierung eines Beispiels stellte sich heraus, dass es mit dem schnellen Zusammenklicken eines Modells auch nicht so weit her ist, da etliche Randbedingungen eingestellt werden müssen, die oftmals gut Versteckt in irgendwelchen Menüs stecken. • Auch die Nutzung von Simulink und Stateflow bedarf einer gewissen Einarbeitung. Die allerdings im Vergleich zur Einarbeitung in eine der Programmiersprachen für den RCX geringer ist. Diese bieten dafür größeren Funktionsumfang.

36. Bewertung • Die Arbeit mit Simulink und Stateflow an sich, zur Modellgenerierung, ist eine interessante Möglichkeit. • für die RCX-Programmierung stehen allerdings Aufwand und Nutzen in schlechter Relation • bisher hat sich keine Entwicklergemeinde des ECRobot angenommen • ECRobot ist zwar kostenlos, aber für die zu Nutzende Basis Matlab trifft dies nicht zu • die Programmiersprachen für den RCX, wie NQC, sind meiner Ansicht nach weitaus mächtiger im Funktionsumfang und bedürfen vermutlich nur eines gering größeren Einarbeitungsaufwandes für jemanden mit Programmiererfahrung