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

9 Planung2 zu COACH2

Gesamtkonzept für einen Vehikelschwarm

Motivation

Ankündigung für den Tag der Offenen Tür an der FH-Brandenburg am Freitag 11.06.2010

Schwarm autonomer Vehikel
In diesem Semester haben sich Studierende im Fach
Mechatronik, die kurz vor ihrem Abschluß stehen mit
der Computersimulation, dem Bau und der Verhaltens-
Optimierung eines Schwarms autonomer Vehikel
beschäftigt. Teile dieser Arbeiten können von
den Besuchern an interaktiven Testständen erkundet werden.
Zeit: 12 bis 15Uhr
Raum: IWZ 135
 

Code 9-1: Ankündigung für den Tag der Offenen Tür

Anforderungen

  • Im folgenden wird ein Konzept entwickelt, um Experimente mit dem Vehikelschwarm durchführen zu können.
  • Die angestrebte Anordnung soll folgenden Anforderungen genügen:
  1. Änderungen an den verwendeten Regelalgorithmen und den verwendeten individuellen Verhaltensregeln jedes Fahrzeugs sollen "on the fly" durchgeführt werden können.
  2. Es soll eine Simulationsumgebung geben, mit deren Hilfe Parameteroptimierungen für das Schwarmverhalten durchgeführt werden können.
  3. Es soll eine Simulationsumgebung geben, mit deren Hilfe Parameteroptimierungen für die Regelalgorithmen der individuellen Fahrzeuge durchgeführt werden können.
  4. Beide Simulationsumgebungen sollen auch synchron mit dem realen Prozeß ablaufen können.
  5. Eine Visualisierung soll es ermöglichen, reale und simulierte Vehikel, sowie reales und simuliertes Schwarmverhalten zu superpositionieren.
  6. Es soll ein möglichst wenig aufwändiges System geben, mit dessen Hilfe die Positionen aller Vehikel erfaßt werden kann, um diese Daten für die Echtzeitvisualisierung zu nutzen.
  7. Das Gesamtsystem soll offen und modular sein. D.h. aus vereinfachten Vorversuchen sollen die einzelnen Komponenten entwickelt werden und Visualisierung, Simulationsumgebung, Funkkommunikation, etc. sollen eine möglichst schwache Bindung untereinander haben, so, dass einzelne Teile immer wieder durch verbesserte ersetzt werden können und alternativ auch kleinere Versuchsanordnungen auf der Grundlage der verfügbaren Module zügig umgesetzt werden können.

Konzeptentwurf

  • Bei der Auswahl der im folgenden aufgeführten Realisierungstechniken, lag das Augenmerk zunächst darauf, durchweg Elemente zu verwenden, mit denen bereits praktische Erfahrungen gemacht wurden und deren Funktionieren damit zunächst für sich genommen gewährleistet ist.
  • Außerdem wurden den verfügbaren "High-Level-Tools", wie Labview, Scilab, etc. eher solche vorgezogen, die elementarer sind, wie C++ und Java-Programmierung und mit denen deshalb die Entwicklung auch aufwändiger ist.
  • Der Grund hierfür liegt darin, dass die miteinander zu verbindenden Komponenten, wie z.B. die Regelkreise auf den Fahrzeugen, die Simulatoren, die Visualisierungen, die Optimierer etc. sich nicht in einer einzigen Entwicklungsumgebung integrieren lassen. Die "High-Level-Tools" erkaufen aber stets die Möglichkeit mit ihnen einen bestimmten Typ von Modul schneller entwickeln zu können, mit einer gewissen Hermetik, was die Möglichkeiten betrifft, dieses Modul in einen anderen Kontext einzubetten, oder umgekehrt in dieses Modul andere Module einzubetten.
  • Natürlich findet man in den Beschreibungen der "High-Level-Tools" stets Beschreibungen eben dafür. Jedoch wird dann stets ein erheblicher Aufwand betrieben, um das einzubettende fremde Element so weit zu zähmen, dass es integrierbar wird.
Aufgabe der Schwarmintelligenz
  • Aus zufälligen Startpositionen in einem umschlossenen Rechteck heraus, sollen die Fahrzeuge nach einiger Zeit dazu übergehen in einem Konvoi zu fahren.

Szenario 1 (Erste Möglichkeit)

Hardwarekonfiguration Vehikel
  • 45o Entfernungssensor / AD-Wandler
  • Drehgeber / Hauptprogramm ohne Interrupts
  • Antrieb / PWM Timer 1
  • Servo / PWM Timer 1
  • Funkmodul / Hauptprogramm
  • IR-Sender / PWM Timer oder Hauptprogramm, verschiedene Frequenzen
Hardwarekonfiguration Vehikelschwarm
  • PC über Mikrocontroller-Boardmit mit Funkmodul verbunden.
  • 5 Fahrzeuge mit Funkmodul.
  • Entlang Wandung: 5..15 IR-Empfänger, empfindlich für verschiedene Frequenzen zur Positionserfassung der Vehikel.
  • Strategie wird auf PC festgelegt, jedoch jedes Fahrzeug ist Individuum.

Szenario 2 (Zweite Möglichkeit)

Verzicht auf ständigen Funkkontakt zu PC
  • 45o Entfernungssensor / AD-Wandler
  • Drehgeber / Hauptprogramm ohne Interrupts
  • Antrieb / PWM Timer 1
  • Servo / PWM Timer 1
  • Funkmodul / Interrupt
  • KEINE IR-Sender
  • PC über Mikrocontroller-Boardmit mit Funkmodul verbunden.
  • 5 Fahrzeuge mit Funkmodul.
  • KEINE IR-Empfänger
  • Strategie wird in Form einer sehr einfachen Skriptsprache per Funk vom PC auf die Fahrzeuge übertragen, dann werden die Fahrzeuge für 3 Minuten fahren gelassen.

Diskussion der Szenarien

  • Szenario 1 bietet prinzipiell die Möglichkeit Simulation und reales Fahrverhalten in Echtzeit zu superpositionieren.
  • Szenario 1 erlaubt es auch aufwändigere Strategien auf dem PC berechnen zu lassen.
  • Szenario 1 birgt Unwägbarkeiten, was die Kombination von Funkverkehr und Vehikelsteuerung betrifft.
  • Szenario 2 wirkt aufgrund der Autonomie der Vehikel überzeugender. - Es verleitet nicht so sehr zu dem Verdacht, noch bietet es die Möglichkeit, die Fahrzeuge von einem zentralen Punkt ferzusteuern.
  • Szenario 2 birgt die Unwägbarkeit, erfolgreich eine einfache Skriptsprache zur Übertragung der Fahrstrategien über Funk zu entwickeln.

Klärung der Machbarkeit

Verfügbare Komponenten
  • Fahrzeuge bisher ohne Funkmodule, aber Steckplatz vorbereitet und Erfahrung aus COACH1. Für Szenario 1 IR-Sender noch einzubauen.
  • Weitere Erfahrung mit Funkmodul: 2 Mobile GPS-Stationen, die an stationäre PC-Station Daten schicken und auch von dieser Daten empfangen.
  • Drehgeber und Servoposition können eingesetzt werden, um zurückgelegten Weg durch Integration zu erfassen.
  • Java-Programm zur Kommunikation über die serielle PC-Schnittstelle.
  • Java-Programm zur Animation von Simulationsergebnissen.
  • Java-Programm zur Kommunikation mit anderen PCs im Netzwerk.
  • Java-Programm zur Simulation, Optimierung, Ergebnisdarstellung.
Sichtung der verschiedenen Tätigkeiten
  • Zeitplanung
  • Vehikel entmotten, Konvergenz auf einheitliche Software, vergleichende Testläufe.
  • Parameteridentifikation bei den Vehikeln.
  • Modellierung der Vehikel.
  • Simulation und Optimierung verschiedener Konzepte für das Schwarmverhalten.
  • Aufbau der Funkstrecke / Planung des Ablaufprotokolls.
  • Szenario1: Erstellen der Skriptsprache.
  • Szenario2: IR-Sender/Empfänger aufbauen und testen / Positionserkennung.
  • Szenario2: Problem der Kombination Funkverkehr/Drehzahlerfassung lösen.
  • Poster für verschiedene Simulationen erstellen, Besucherfreundliche Oberflächen zum Auslösen von Testläufen.
  • Besucherfreundliche Auswahlmöglichkeit verschiedener Fahrstrategien über Benutzeroberfläche.

Puck

Aufgabe
  • Schreiben Sie ein Java-Programm zur Simulation und Animation eines Partikelschwarms.
  • Überlegen Sie sich Konzepte zur Realisierung eines Verhaltens bei dem sich die Partikel aus zufälligen Anfangszuständen heraus schließlich in einen Konvoi / Kreisfahrt eingliedern.
  • Nutzen Sie das Animationsprogramm mit der Doppelpufferung des Grafikbereichs unter dem Menüpunkt "Java" und das Programm zur Reglereinstellung nach Ziegler-Nichols.
  • Die Modellierung wird in der Vorlesung besprochen.
Hinweise zum Vorgehen bei der Lösung der Aufgabe

Schritt 1: Modellierung eines passiven Pucks von Hand

  • Formulieren Sie die Newton-Bewegungsgleichungen in der Ebene für einen Puck.
  • Ein Puck ist geometrisch eine flache Scheibe, dessen Masse als konzentriert im Mittelpunkt angenommen wird.
  • Mögliche Form (vektorielle Gleichung) ma=FD+SummeFKi
  • FD - lineare Dämpfung -D[vx;vy]
  • SummeFK - Summe der auftretenden Kollisionskräfte
  • Die Kollisionskräfte entstehen immer dann, wenn eine Wand oder ein anderer Puck in den Puck eintritt.
  • Der Betrag einer Kollisionskraft soll zunächst linear mit der Eindringtiefe ansteigen.
  • Die Wirkrichtung einer Kollisionskraft soll immer entlang der kürzesten Verbindung der kollidierenden Pucks wirken.
  • Bei Wandkollision soll die Wirkrichtung entlang der Strecke Puckmittelpunkt - Mitte der Verbindung beider Randschnittpunkte mit der Wand wirken.

Schritt 2: Umsetzung eines enzelnen Pucks als Simulationsmodell

  • Setzen Sie ein Puckmodell mit Hilfe der Java-Klassen "Modell.java" und "Integrator.java" um.
  • Passen Sie das Modell an und schreiben Sie dazu eine Java-main-Methode, die die Bewegungsdaten auf der Konsole ausgibt.
  • Mit dem Aufruf java MeinProgramm > data.txt werden Ihre Bewegungsdaten in die Datei data.txt geschrieben (Format einer Zeile sollte sein: t x y vx vy)
  • Lesen Sie die Bewegungsdaten in Scilab ein und plotten Sie diese zur Kontrolle.
  • Einlesen in Scilab: m=fscanfMat('data.txt')
  • Ein einzelner Puck sollte bei einer Anfangsgeschwindigkeit ungleich Null ein paarmal an den Wänden kollidieren und dann zur Ruhe kommen.

Schritt 3: Visualisierung eines einzelnen passiven Pucks in Java

  • Nutzen Sie die verfügbaren Animationsbeispiele, um Ihren Puck in einem Applet zu animieren.
  • Skalieren Sie den Puck und den umgebenden Raum (Rechteck) für die verfügbare Darstellungsgröße passend.

Schritt 4: Interaktion mehrerer passiver Pucks

  • Ein Modell ist bisher ein Objekt und so sollte es auch bleiben.
  • Um die Interaktion zwischen den Pucks realisieren zu können, müssen alle Modell-Objekte auch Zugriff auf die aktuellen Zustandsvariablen aller anderen Modellobjekte erhalten.
  • Dies läßt sich beispielsweise dadurch bewerkstelligen, dass im Applet-Objekt als Objekt-Attribut der aktuelle Systemzustand als Array oder mehrere Arrays gespeichert wird und alle Modelle eine Referenz auf das Applet-Objekt erhalten.
Kollision zweier Pucks

Bild 9-1: Kollision zweier Pucks - Richtung ergibt sich aus Verbindungslinie der Mittelpunkte, Betrag: k(s-2r)

Schritt 5: Aktives Verhalten

  • Führen Sie in die Modellgleichungen Ihres Puck-Modells eine Antriebskraft FAntrieb ein.
  • Die beiden Komponenten der Antriebskraft sollen nach bestimmten Regeln berechnet werden.
  • Erstes Experiment: Setzen Sie die Antriebskraft für alle Pucks so, dass diese jeweils immer in eine bestimmte Ecke des Raumes gerichtet ist.
  • Die Pucks sollten sich dann nach einer Weile dort sammeln.
  • Es wird nun notwendig sein, die Kollisionskräfte zu dämpfen.

Schritt 6: Schwarmverhalten

  • Jetzt wird es kreativ:
  • Finden Sie möglichst einfache Regeln für das einzelne Puckverhalten, dass diese sich nach einiger Zeit in einem Konvoi in einer Kreisbahn, oder etwas schönerem, im Raum bewegen.
  • Die Kunst bei der Implementierung von Schwarmverhalten liegt vor allem darin, einfache Regeln für das Individuum zu finden, und dadurch ein möglichst intelligent erscheinendes Verhalten des Schwarms zu evozieren.
  • Dass die Regeln im besten Fall einfach sind und komplexes Verhalten hervorrufen, wird in solchen Fällen durch die Interaktion der Entitäten untereinander und mit ihrer Umgebung bewirkt.
  • Die Komplexität der Umgebung fließt dadurch sozusagen mit ein und die Überlegung bei der Formulierung der Regeln sollten deshalb auch dahin gehen, die Eigenschaften der Umgebung zu nutzen.

Schritt 7: Realistischere Modelle

  • Nun sollten die Modelle realistischer gestaltet werden.
  • Insbesondere sollten sie nicht mehr die Information über die gesamte Umgebung haben, sondern nur über ihren Nahbereich, ev. nur in Fahrtrichtung, bzw. 45o dazu entsprechend den Eigenschaften der COACH-Vehikel.
  • Als weiterer Schritt in Richtung COACH-Vehikeln, kann die Bewegungsrichtung auf eine Richtung beschränkt werden und alle Kräfte dagegen zu Null gesetzt werden (Räder ohne Schlupf).
  • Die Bewegungsrichtung kann dann nur aktiv durch Drehen geändert werden.
  • An irgendeiner Stelle sollte man dann abbrechen und direkt über die Modellierung der Vehikel nachdenken.