kramann.info
© Guido Kramann

Login: Passwort:










COACH2
1 Planung
2 Architektur
3 Anzeige
4 EEPROM
5 I2C
..5.1 MasterSendByte
..5.2 MasterSend2Bytes
..5.3 MasterReceiveByte
..5.4 MasterReceive2Bytes
6 UART
7 DFT
8 FFT
9 Planung2
10 Klassen
..10.1 AnzeigeTaster
..10.2 RS232
..10.3 MotorServo
..10.4 Drehgeber
..10.5 Sensor
..10.6 Funk
11 Adaption
..11.1 Programmiertechnik
..11.2 Evoopt
12 Fuzzy
..12.1 Uebungsaufgabe
..12.2 Fuzzygroesse
..12.3 Fuzzyset
..12.4 Lookuptable
13 Skript
..13.1 Funkkorrektur
..13.2 Skriptsprachen
..13.3 Anforderungen
..13.4 Agentensysteme
..13.5 Implementierung
..13.6 Experimente
14 Gesamtkonzept
..14.1 Skripterweiterung
..14.2 Makroverhalten
67 Echtzeitsysteme
..67.1 Einfuehrung
....67.1.1 Echtzeit
....67.1.2 Korrektheit
....67.1.3 Hardware
....67.1.4 Ziele
....67.1.5 Synchronprogramm
..67.2 Threads
....67.2.1 Java
....67.2.2 Synchronisierung
..67.3 COACH
....67.3.1 Kaskadenregler
....67.3.2 Zeitebene1
....67.3.3 Zeitebene2
....67.3.4 Zeitebene3
....67.3.5 Puck
....67.3.6 Puckschwarm
..67.4 RTAIlab
....67.4.1 Slax
....67.4.1 USB_Stick
....67.4.2 Sinus
..67.5 Semaphor
....67.5.1 Laufkatze
....67.5.2 Java
....67.5.3 Semaphor
..67.6 Audio
....67.6.1 wav
....67.6.2 Linux
..67.7 Lookup
....67.7.1 Fuzzy
....67.7.2 PWM
..67.8 NeuronaleNetze
....67.8.1 Neuron
....67.8.2 Backpropagation
....67.8.3 Umsetzung
....67.8.4 Winkelerkennung
..67.9 Internetprogrammierung
....67.9.1 Codegenerierung
....67.9.2 PHP_Programmierung
....67.9.3 PHP_OOP
....67.9.4 Java
....67.9.5 UDP
..67.10 DFT
..67.11 FFT
..67.12 Zustandsmaschine
..67.13 Fuzzy
....67.13.1 Fuzzylogik
....67.13.2 FuzzyRegler
....67.13.3 Uebung9
....67.13.5 Softwareentwicklung
......67.13.5.1 AgileSoftwareentwicklung
......67.13.5.2 FuzzyRegler
......67.13.5.3 Uebung
....67.13.6 Umsetzung
......67.13.6.1 FuzzyRegler
......67.13.6.2 Simulation
......67.13.6.3 Optimierung
......67.13.6.4 Uebung
....67.13.7 Haengependel
......67.13.7.1 Haengependel
......67.13.7.2 Simulation
......67.13.7.3 FuzzyRegler
......67.13.7.4 Optimierer
......67.13.7.5 Genetisch
....67.13.8 Information
....67.13.9 Energie

13.3 Untersuchung der Anforderungen an eine für die COACH-Vehikel zu entwickelnde Skriptsprache

  • Die Resourcen auf dem verwendeten Mikrocontroller sind sehr begrenzt.
  • Durch die Verwendung einer Vielzahl an Klassen sind sie zudem bereits fast erschöpft.
  • Ein Compiler greift in der Regel von vorne beginnend kleinste nicht weiter zerlegbare Einheiten des Quelltextes ab und überführt sie zunächst in eine Baumstruktur.
  • Schlüsselwörter müssen erkannt werden, die Syntax überprüft werden und nach einer optimalen Umsetzung in Maschinensprache gesucht werden.
  • Von diesen und vielen weiteren Arbeitsschritten werden bei den Interpretern von Skriptsprachen i.d.R. nur ein Teil umgesetzt.
  • Skriptsprachen sind oft nur der Kitt zwischen kompilierten Komponenten und können entsprechend einfacher auf die konkreten Bedürfnisse abgestimmt werden.
  • So auch in unserem speziellen Fall:
  • In der Endlos-While-Schleife des Hauptprogramms für den Mikrocontroller wird typischerweise eine Folge von Funktionen aufgerufen.
  • Diese Funktionen benötigen entweder Übergabeparameter und/oder liefern Ergebnisse zurück.
  • Es besteht kein Interesse daran, das, was diese Funktionen machen (Sensordaten lesen, Motor-PWM-Signal einstellen etc.) durch Skripte zu realisieren.
  • Vielmehr wird es eher darum gehen, die Abfolge und Art und Weise, wie die verfügbaren Funktionen aufgerufen werden flexibel festlegen zu können.
  • Dies würde ausreichen, um einen einfachen Reflex-Agenten realisieren zu können.
  • Die Programmstruktur könnte sich leicht an dem Konzept der Synchronen Programmierung (s. Echtzeitsysteme) orientieren.
  • Auf den Mirkocontroller angewendet, gibt es hier eine feste Dauer eines Durchlaufs der Endlosschleife.
  • Und in jedem Zyklus kann ein anderer Befehl, d.h. der Aufruf einer anderen Funktion erfolgen.
  • Eine bestimmte Anzahl an Schleifendurchläufen würde dann einem vollen Zyklus entsprechen.
  • Man kann sich dabei an der gewünschten Reaktionszeit des Vehikels orientieren:
  • Angenommen diese würde mit 1/5 (0,2s) Sekunde angesetzt, dann stünden bei einer Dauer eines Schleifendurchlaufs von 1ms (0,001s) 200 Funktionsaufrufe zu Verfügung.
  • Es kann dabei Funktionen geben, die innerhalb eines Zyklus oft aufgerufen werden, wie das Auffrischen der Anzeige oder das Aktualisieren der Sensordaten (neuen Wert in einen "Ringspeicher" holen).
  • Andere werden nur einmal innerhalb eines Zyklus aufgerufen, wie z.B. das Setzen eines neuen PWM-Antriebssignals (vergl. nachfolgendes Schema zu Synchroner Programmierung).
Synchrone Programmierung.

Bild 13.3-1: Synchrone Programmierung.

  • Dieses Verschränken von häufig aufgerufenen Prozessen mit seltener benutzten Funktionen, entspricht in etwa dem Schema, das wir vom Scheduling bei RTAI-Linux kennengelernt haben:
Verteilung der Prozessorzeit bei RTAI-Linux.

Bild 13.3-2: Verteilung der Prozessorzeit bei RTAI-Linux.

  • Soll aber mehr als ein einfacher Reflexagent umgesetzt werden, so benötigt man auch ein "Gedächtnis", in dem im einfachsten Fall vergangene Sensorwerte und resultierende Aktionen gespeichert werden, um diese bei der Planung des Verhaltens verwenden zu können.
  • Damit wäre in einfacher Weise ein Erfahrungsspeicher umsetzbar.
  • Ein Integralanteil bei einem PID-Regler ist auch schon eine Art "Erfahrungsspeicher": Hier wirkt sich die in die Vergangenheit zurückliegende Regelabweichung auf das aktuelle Verhalten aus.
  • Zur Orientierung sollen im nachfolgenden Kapitel die Typen von Agentensystemen besprochen werden.