kramann.info
© Guido Kramann

Login: Passwort:










EmbSyst
1 day_by_day
2 Eingebettete_Systeme
..2.1 Softwareentwicklung
....2.1.1 AgileSoftwareentwicklung
....2.1.2 Verhalten
....2.1.3 Entwurfsmuster
....2.1.4 FuzzyRegler
....2.1.5 Uebung
..2.2 Arduino
....2.2.1 Uebung1
..2.3 Android
....2.3.1 UML
......2.3.1.1 Volumenberechnung
......2.3.1.2 UML_Klassendiagramm
......2.3.1.3 Konstruktor
......2.3.1.4 Statische_Variable
....2.3.2 bluej
....2.3.3 Threads
....2.3.4 Interfacedesign
....2.3.5 Android
......2.3.5.1 Getting_Started
......2.3.5.2 App
......2.3.5.3 Beispielprojekt
........2.3.5.3.1 Richtlinien
........2.3.5.3.2 Anforderungen
........2.3.5.3.3 Layout
........2.3.5.3.4 Projekt_einrichten
........2.3.5.3.5 Refactoring
........2.3.5.3.6 Icon
........2.3.5.3.7 Icon2
........2.3.5.3.8 Kurzanleitung
........2.3.5.3.9 Architektur
........2.3.5.3.10 Anwendungsklasse
......2.3.5.4 Threads
......2.3.5.5 Activities
......2.3.5.6 Was_ist_wo
......2.3.5.7 Regelungssysteme
........2.3.5.7.1 Servo
........2.3.5.7.2 Fahrzeug
......2.3.5.8 ADB_Apps
......2.3.5.9 Veroeffentlichen
......2.3.5.10 Einzelheiten
........2.3.5.10.1 Bildschirmaufloesung
........2.3.5.10.2 Parameter
........2.3.5.10.3 Permission
........2.3.5.10.4 Latenzzeit
......2.3.5.11 Tonerkennung
........2.3.5.11.1 Wahrscheinlichkeitsrechnung
........2.3.5.11.2 Kovarianz_Scilab
........2.3.5.11.3 Java_Threads
........2.3.5.11.4 Java_Reflection
....2.3.6 Processing
......2.3.6.1 Installation
......2.3.6.2 Erste_Schritte
......2.3.6.3 Mechatronik
......2.3.6.4 Bibliotheken
......2.3.6.5 Uebung
......2.3.6.6 Snippets
........2.3.6.6.1 Dateioperationen
........2.3.6.6.2 Bilder
........2.3.6.6.3 GUI
........2.3.6.6.4 Text
........2.3.6.6.5 PDF
........2.3.6.6.8 Maus
........2.3.6.6.10 Zeit
........2.3.6.6.13 Animation
........2.3.6.6.15 Simulation
......2.3.6.7 Referenzen
....2.3.7 Android_Processing
......2.3.7.1 Basics
......2.3.7.2 Einrichten
......2.3.7.3 Crossplattform
......2.3.7.4 sinus
......2.3.7.5 sample
......2.3.7.6 analyse
......2.3.7.7 synthese
......2.3.7.8 Hilfsapps
......2.3.7.9 Eigene_Library
....2.3.8 Processing_VR
....2.3.9 Shapes3D
....2.3.10 TextToSpeech
....2.3.11 Internetprogrammierung
......2.3.11.1 Codegenerierung
......2.3.11.2 PHP_Programmierung
......2.3.11.3 PHP_OOP
......2.3.11.4 Java
......2.3.11.5 UDP
......2.3.11.6 Internetkontrolle
........2.3.11.6.1 Kamerabild
....2.3.12 OSC
......2.3.12.1 Datenaustausch
......2.3.12.2 i2audiolab
......2.3.12.3 Ardour
....2.3.13 Netzwerkprogrammierung
....2.3.14 JNI
....2.3.15 Erweitern
......2.3.15.1 sprich
......2.3.15.2 spiel
....2.3.16 thbvr
....2.3.17 Reflection
....2.3.18 Script
....2.3.19 Java3D
3 Echtzeitprogrammierung
..3.1 Echtzeit
..3.2 Korrektheit
..3.2 Semaphoren
..3.3 Hardware
..3.5 Synchronprogramm
..3.6 Zustandsmaschine
..3.7 Arduino
....3.7.1 Uebung
....3.7.2 RTOS
....3.7.3 Scheduler
....3.7.4 Semaphor
......3.7.4.1 Laufkatze
......3.7.4.2 Java
......3.7.4.3 Semaphor
....3.7.5 Messages
..3.8 Android
....3.8.2 Threads
......3.8.2.1 Java
......3.8.2.2 Synchronisierung
..3.9 Petrinetze
....3.9.1 Installation
....3.9.2 Test
4 KI
..4.1 Unueberwachtes_Lernen
..4.2 Agentensysteme
....4.2.1 Architekturen
......4.2.1.1 Verhalten
......4.2.1.2 Entwurfsmuster
....4.2.2 SUMO
......4.2.2.1 GettingStarted
......4.2.2.2 Antrieb
......4.2.2.3 Sensoren
......4.2.2.4 Zeitbasis
......4.2.2.5 Fernsteuerung
......4.2.2.6 Umsetzung_Fernst
......4.2.2.7 Fernsteuerung3
......4.2.2.10 Umsetzung
......4.2.2.11 Sockelsoftware
......4.2.2.12 Plan
......4.2.2.13 Lernen
........4.2.2.13.1 Parameter
........4.2.2.13.2 Identifikation
........4.2.2.13.3 Java
..4.3 Genetische_Algorithmen
....4.3.1 Heuristiken
....4.3.2 Genalgorithmus
..4.4 Kalmanfilter
....4.4.1 Vorarbeit
....4.4.2 Minimalversion
....4.4.3 Beispiel
5 Bildverarbeitung
..5.1 Gestalttheorie
..5.2 Bildverarbeitung
6 Technische_Systeme
..6.1 Kulturgeschichte
..6.2 Technikphilosophie
..6.3 Anthropozaen
7 Literatur
kramann.info
© Guido Kramann

Login: Passwort:




Beschreibungsmethoden für Verhaltens orientierte Robotik

(EN google-translate)

(PL google-translate)

Man mag sich nachfolgend vielleicht darüber beschweren, dass Übergangsgraphen und UML-Diagramme, Schnittstellen und vieles andere nur unzureichend in dem vorangegangenen Studium behandelt wurden. Jedoch denke ich, ohne die Probleme zu kennen, die mit ihnen gelöst werden sollen, ist es unmöglich den Sinn bestimmter Werkzeuge zu verstehen. Darum werden diese Dinge in diesem, im nächsten und auch weiteren Kapiteln "en passant" (im Vorbeigehen) eingeführt.

  • Quelle: Arkin, R.C., "Behavior-Based Robotics", MIT Press, Cambridge 1998.

Formale Beschreibungsnethoden für das Verhalten autonomer Systeme ermöglichen ...

  • ..Klarlegen der Absicht des Entwicklers,
  • Leichtere Analyse-Möglichkeit eines Programms, als dessen Implementierung, um beispielsweise die Vollständigkeit oder Adäquatheit einer Lösung zu erkennen,
  • komplexe Regelsysteme korrekt zu implementieren.

Reiz-Reaktions-Diagramme

Reiz-Reaktions-Diagramme (Stimulus-response diagrams / SR) ist eine informelle Methode Verhalten in Blockdiagrammen zu dokumentieren.

Grundstruktur eines Reiz-Reaktions-Diagramms.

Bild 0-1: Grundstruktur eines Reiz-Reaktions-Diagramms.

Diese Art Diagramme wurden bereits im ersten Kapitel informell eingeführt (vergl. erste beiden Diagramme im Hauptkapitel "Architekturen").

Finite Zustands-Diagramme

Finite Zustands-Diagramme (Finite State Diagrams / FSA) eignen sich gut Übergänge und deren Bedingtheit zwischen verschiedenen Zuständen darzustellen.

Ein FSA besteht aus einem Quadrupel von vier Vektoren (Q, δ, q0, F). Diese Elemente haben die folgende Bedeutung:

  • Q: Menge der erlaubten Zustände.
  • δ (kleines griechisches Delta) Menge an Übergangsfunktionen, die Bedingungen Festlegen, unter denen ein Zustand aus Q in einen aus F übergeht.
  • q0: Anfangsbedingungen des Systems.
  • F: Menge der erlaubten Ziel-Zustände, eine Untermenge von Q.
FSA-Diagramm als Petrinetz dargestellt.

Bild 0-2: FSA-Diagramm als Petrinetz dargestellt.

Im obigen Beispiel sind die doppelt umkreisten Zustände terminierende Zustände (terminal states).

Ein FSA-Diagramm ermöglicht es, die Beziehungen zwischen Verhalten und Zuständen auf einem relativ hohem Abstraktionsniveau darzustellen (vergl. Arkin, Behavior-Based Robotics, pp. 79-85).

Kodierung von Verhalten

Während SR und FSA dazu dienen, Verhaltensweisen auszudrücken, wird im folgenden aufgezeigt, wie sich Verhaltensweisen kodieren lassen.

Während in einer Informatikausbildung die Handhabung diskreter Zustände dominieren, haben wir in der Mechatronik viele Arten von beschreibungen für kontinuierliches dynamisches Verhalten kennengelernt.

Zustands-Automat (Situated Automata)

Der Zustands-Automat (Situated Automata) ist eine diskrete Variante für das Kodieren von Verhalten und kann leicht mit den in den gängigen Programmiersprachen verfügbaren Kontroll-Strukturen und logischen Operatoren umgesetzt werden.

Abhängig vom Aktuellen Zustand und hereinkommender Input-Signale werden Bedingungen formuliert, unter denen ein anderer Zustand erreicht wird.

Eine effiziente Umsetzung ist die Verwendung von switch-case-Strukturen in C, C++, oder Java, wobei die Zustände infach durchnummeriert werden können:

while(true)
{
  switch(ZUSTAND)
  {
    case 0: //AV in Ruhe
        if(STARTSIGNAL==true)
        {
            starteSuchbewegung(); //Übergangsoperationen zu Zustand 1
            ZUSTAND = 1;
        }
    break;
    case 1: //AV sucht die Ladestation
        if(SIGNAL_DER_LADESTATION_EMPFANGEN==true)
        {
           stoppeSuchbewegung();
           ZUSTAND = 2;
        }
        if(FEHLERMELDUNG==true)
        {
           stoppeSuchbewegung();
           ZUSTAND = 3;
        }
    break;    
    case 2:
        //terminierender Zustand, wird nicht mehr verlassen.
    break;
    default: //Fehlerzustand
        sendeHilfemeldung();
    break;
  }

  FÜHRE_AKTUELLEN_ZUSTAND_AUS
}

Code 0-1: Beispiel eines Zustands-Automaten (Finite-State-Automata / FSA) in C.

Kontinuierliche Funktionale Kodierung (Continous Functional Encoding)

Das Verhalten eines Fahrzeugs, das einen Zielpunkt anvisieren soll, aber Hindernissen ausweichen soll, kann auch über kontinuierliche Funktionen beschrieben werden.

In der Regelungstechnik haben wir als Stellgröße häufig die Kraft, die als Antrieb auf ein Fahrzeug wirkt betrachtet. Nun kann man ja dafür sorgen, dass auf ein fiktives sehr einfaches Fahrzeug (man stelle sich einen Puck auf einer Eisfläche mit Steuerraketen vor) immer eine Kraft wirkt, dessen vektorielle Richtung auf den Zielpunkt gerichtet ist. Dieser Kraft ist aber noch eine zweite überlagert, die bei Annäherung an ein Hindernis quadratisch mit der Annhäherung an dieses ansteigt und entgegen des Verbindungsvektors Fahrzeug zum Hindernismittelpunkt gerichtet ist.

Zeichnet man den Kraftvektor an jeder Stelle auf der "Eisfläche" ein, so erhält man ein Vektorfeld, das das Verhalten des Fahrzeugs in jedem der möglichen kontinuierlichen Zustände (Fahrzeugposition und Geschwindigkeit) charakterisiert.

Wie man ein solches Vektorfeld mit Skilab darstellt wurde in Kapitel 13.2 in Regelungssysteme besprochen (Analyse nicht linearer Systeme).

Übung

Frischen Sie Ihre Scilab-Kenntnisse auf und entwickeln exemplarisch ein Simulationsmodell für ein System, wie es weiter oben beschrieben wurde (Puck mit Zielpunkt und einem Hindernis).

Führen Sie für das entwickelte System Simulationen mit verschiedenen Anfangsbedingungen aus und stellen die entstehenden Trajektorien in einem Plot dar.

Unterlegen Sie diese Plots mit dem Kraftfeld (Orientierung und Betrag der resultierenden Kraft, die auf den Puck wirkt an vordefinierten Rasterpunkten als kleine Vektorpfeile dargestellt) mit Hilfe von fchamp(..).

puck.zip - Vorlage für Simulationsmodell.
puck2.zip - Musterlösung.