kramann.info
© Guido Kramann

Login: Passwort:










Robuste Systemintegration
1 Grundlagen
..1.1 Newton
....1.1.1 LinearSchwinger
....1.1.2 Daempfung
....1.1.4 ODE
....1.1.5 Saaluebung
..1.2 NewtonEuler
....1.2.1 Traegheitsmomente
....1.2.2 Modellgleichungen
....1.2.3 Einfachpendel
..1.3 Scilab
....1.3.1 Erste_Schritte
....1.3.2 Skripte
....1.3.3 Funktionen
..1.4 Laplace
....1.4.1 Eigenwerte
....1.4.2 PT1
..1.5 Regleroptimierung
....1.5.1 Guetefunktion
....1.5.2 Heuristiken
....1.5.3 Scilab
..1.6 Einstellregeln
....1.6.1 Totzeit
....1.6.2 Methode1
....1.6.3 Methode2
....1.6.4 Scilab
..1.7 Zustandsregler
..1.8 Polvorgabe
..1.8 Polvorgabe_alt
..1.9 Beobachter
....1.9.1 Haengependel
..1.10 Daempfungsgrad
..1.11 Processing
....1.11.1 Installation
....1.11.2 Erste_Schritte
....1.11.3 Mechatronik
....1.11.4 Bibliotheken
....1.11.5 Uebung
....1.11.6 Snippets
......1.11.6.1 Dateioperationen
......1.11.6.2 Bilder
......1.11.6.3 GUI
......1.11.6.4 Text
......1.11.6.5 PDF
......1.11.6.8 Maus
......1.11.6.10 Zeit
......1.11.6.13 Animation
......1.11.6.15 Simulation
....1.11.7 Referenzen
..1.12 Breakout
2 Beispiel
3 Beispielloesung
4 Praxis
5 javasci
6 Fehlertoleranz1
7 Reglerentwurf
..7.1 Sprungantwort
..7.2 Messdaten
..7.3 Systemidentifikation
..7.4 Polvorgabe
..7.5 Beobachter
..7.6 Robuster_Entwurf
..7.7 SIL
8 Systementwicklung
9 Arduino
..9.1 Lauflicht
..9.2 Taster
..9.3 Sensor
..9.12 Motor_PWM1
..9.13 Motor_PWM2_seriell
..9.14 Motor_PWM3_analogWrite
..9.15 Scheduler
..9.20 AV
..9.21 Mikrofon
..9.22 Universal
....9.22.1 Laborplatine
....9.22.2 LED_Leiste
....9.22.3 Motortreiber
....9.22.4 Sensoreingaenge
....9.22.5 Taster
....9.22.6 Tests
....9.22.7 Mikrofon
....9.22.8 Lautsprecher
....9.22.9 Fahrgestell
..9.23 Zauberkiste
..9.24 OOP
....9.24.1 Uebungen
..9.25 AVneu
....9.25.1 Tests
..9.26 DA_Wandler
..9.27 CompBoard
....9.27.1 Tastenmatrix
....9.27.2 ASCIIDisplay
..9.28 CTC
..9.29 Tonerzeugung
10 EvoFuzzy
..10.1 Fuzzy
....10.1.1 Fuzzylogik
....10.1.2 FuzzyRegler
....10.1.3 Uebung9
....10.1.5 Softwareentwicklung
......10.1.5.1 AgileSoftwareentwicklung
......10.1.5.2 FuzzyRegler
......10.1.5.3 Uebung
....10.1.6 Umsetzung
......10.1.6.1 FuzzyRegler
......10.1.6.2 Simulation
......10.1.6.3 Optimierung
......10.1.6.4 Uebung
....10.1.7 Haengependel
......10.1.7.1 Haengependel
......10.1.7.2 Simulation
......10.1.7.3 FuzzyRegler
......10.1.7.4 Optimierer
......10.1.7.5 Genetisch
....10.1.8 Information
....10.1.9 Energie
..10.2 Optimierung
....10.2.1 Gradientenverfahren
....10.2.2 Heuristiken
....10.2.3 ModifizierteG
....10.2.4 optim
..10.3 Genalgorithmus
..10.4 NeuronaleNetze
....10.4.1 Neuron
....10.4.2 Backpropagation
....10.4.3 Umsetzung
....10.4.4 Winkelerkennung
..10.5 RiccatiRegler
11 Agentensysteme
12 Simulation
20 Massnahmen
21 Kalmanfilter
..21.1 Vorarbeit
..21.2 Minimalversion
..21.3 Beispiel
30 Dreirad
31 Gleiter
..31.1 Fehlertoleranz
80 Vorlesung_2014_10_01
81 Vorlesung_2014_10_08
82 Vorlesung_2014_10_15
83 Vorlesung_2014_10_22
84 Vorlesung_2014_10_29
kramann.info
© Guido Kramann

Login: Passwort:




Fehlertolerante Programmierung der Gleiter-Regelung

(EN google-translate)

(PL google-translate)


gleiter3_leer.sce.zip - Ausgangspunkt für die fehlertolerante Programmierung der Gleiter-Regelung.

Für den Gleiter soll nun beispielhaft eine fehlertolerante Programmierung durchgeführt werden und die Programmteile gemäß den zuvor besprochenen "Patterns for Fault Tolerant Software" (Kapitel 6) geplant bzw. identifiziert werden.

Hauptziel der Fehlertoleranten Programmierung ist die Abschwächung der Wirkung von möglicherweise auftretenden Störungen. Diese sollen nach Möglichkeit nicht gleich zu einem Versagen des Systems führen.

Gleichwohl gibt es Störungen, denen mit selbsttätig durchführbaren Handlungen des Fahrzeugs nicht mehr beizukommen ist. Auch dies sollte vom Fahrzeug erkannt werden und entsprechende Aktionen ausgeführt werden, z.B. stehenbeleiben und Hilfe holen.

Beschränkungen dieser Umsetzung

Aufgrund des hohen Vereinfachungsgrades des Simulationsmodells, können bei weitem nicht alle "Patterns for Fault Tolerant Software" hier sinnvoll eingesetzt werden. Beispielsweise können in diesem Modell der Sensor und die (nicht vorhandene Hardware - z.B. bei partiellem Stromausfall) keine Störungen erfahren und so braucht es keinen Observer, der diese Dinge überwacht, oder einen zweiten redundanten Sensor, der bei Ausfall des ersten verwendet wird. Jedoch ließen sich im weiteren Verlauf durchaus auch weitere Pattern sinnvoll einsetzen, wenn das Simulationsmodell entsprechend erweitert wird. Beispielsweise könnte ein zweiter Sensor eingesetzt werden, der in anderen Situationen gut arbeitet als der erste und beide über zwei Recovery-Blöcke alternativ verwendet werden: Wenn mit dem ersten keine plausiblen Ergebnisse erzielt werden, nimm den zweiten.

Eskalationsstufen

Eine gute Aufteilung der Möglichkeiten zur Abschwächung der Wirkung von Störungen, gibt die Aufteilung der vorausschauend identifizierten möglichen Situationen in Eskalationsstufen.

Innerhalb seiner stark vereinfachten Umgebung können bei dem Gleiter grundsätzlich drei aktuelle Situationen unterschieden werden:

  1. Der Gleiter befindet sich mitten auf der Bahn, so, dass das Sensorfeld komplett hell ist.
  2. Der Gleiter befindet sich in der Nähe des Randes der Bahn, so, dass das Sensorfeld teilweise hell und teilweise dunkel ist.
  3. Der Gleiter befindet sich ganz außerhalb der Bahn, so, dass das Sensorfeld vollständig dunkel ist.

In dieser einfachen Umsetzung einer fehlertoleranten Programmierung der Gleiter-Regelung, soll der Gleiter kein Gedächtnis für den Verlauf der Sensorwerte haben.

In Situation 3 (Gleiter außerhalb Bahn) könnte in einer späteren Version noch versucht werden, die Umgebung langsam nach dem Bahnrand abzusuchen. Dies soll in einer ersten Version zunächst noch nicht passieren. Damit bleibt für das Fahrzeug nichts anderes, als stehen zu bleiben. Dies ist die extremste Situation, die auftreten kann. In diesem Fall kann die "Aufgabe" gegen Uhrzeigersinn im Kreis zu fahren nicht mehr erfüllt werden. Bei der Aufteilung in Eskalationsstufen entspricht dies dann der höchsten Eskalationsstufe.

Beim Erreichen des Randes ist ein Eingreifen eines Regelmechanismus erforderlich, um ein Verlassen der Bahn zu vermeiden. Dies ist eine geringere Eskalationsstufe, als die, bei der die Bahn verlassen wurde. Es stellt eine unmittelbare Gefahr dar, wenn die Bahn verlassen wird, weil danach keine Navigation des Fahrzeugs mehr möglich sein wird.

Je nach Güte der Implementierung der eigentlichen Fahrtregelung mag es passieren, dass das Fahrzeug mitten auf dem Weg stehen bleibt, weil keine Antriebskraft mehr vorgegeben wird und es durch die Dämpfung vollständig abgebremst wurde. Da auch der Sensor keine nützliche Information liefert, außer, dass sich das Fahrzeug mitten auf der Fahrbahn befindet, nimmt es aufgrund der normalen Regelung dann wahrscheinlich keine Fahrt mehr auf. Hier könnte ein kleiner Schubs helfen, was dann einer noch niedrigeren Eskalationsstufe entspricht.

Schließlich kann es sein, dass die verlangte Aufgabe nicht richtig erfüllt wird. Beispielsweise könnte das Fahrzeug statt gegen Uhrzeigersinn im Uhrzeigersinn die Bahn entlangfahren, sich auf der Bahn in suboptimaler Weise (Zick-Zack) bewegen, oder nur in einem Abschnitt hin- und herfahren. Dies sind weniger dramatische Situationen, die aber auch vom Fahrzeug selbsttätig erkannt und verbessert werden können sollten.

Somit ergeben sich grob vier deutlich in ihrer Extremheit unterscheidbare Grundsituationen, auf die mit drei unterschiedlichen Eskalationsstufen reagiert werden sollte:

  1. Das Fahrzeug führt nicht die verlangte Bewegung auf der Bahn aus.
  2. Das Fahrzeug steht mitten auf der Strecke und benötigt einen Antriebspuls um wieder loszufahren.
  3. Das Fahrzeug droht die Bahn zu verlassen.
  4. Das Fahrzeug hat die Bahn verlassen.

Die Umsetzung der Programm-Lösung soll nun in Stufen erfolgen, wobei mit der höchsten Eskalationsstufe begonnen wird und dann nach und nach die davor stehenden und natürlich auch ein Konzept zur Bewältigung der gestellten Aufgabe (gegen Uhrzeigersinn auf der Bahn fahren) ergänzt werden.

Erste Umsetzungsstufe: Eskalationsstufe 4 - Fahrzeug hat die Bahn verlassen

gleiter4_Eskalation4.sce.zip - Realisierung der vierten Eskalationsstufe.

Arbeitsweise: Sobald in der Sensormatrix keine hellen Elemente (Fahrbahn) mehr enthalten sind, wird mittels Fx und Fy eine starke Dämpfungskraft entgegen dem momentanen Geschwindigkeitsvektor aufgebracht:

    if ( sensorsumme==0 ) then
        Fx = -30*vx;  //entgegen Fahrtrichtung Dämpfung stark erhöhen.
        Fy = -30*vy;
    end

Code 0-1: Codeausschnitt zur Realisierung der 4. Eskalationsstufe.

Zweite Umsetzungsstufe: Eskalationsstufe 3 - Fahrzeug läuft Gefahr, die Bahn zu verlassen und wird daran gehindert

gleiter5_Eskalation3.sce.zip - Ergänzung der dritten Eskalationsstufe zur dritten.

Arbeitsweise: Sobald der Mittelpunkt des Gleiters aus der Fahrbahn herausragt, reagiert das Fahrzeug so, als wäre es über eine Feder mit der Fahrbahn verbunden und würde zurück gezogen werden.

Der Verbindungsvektor der Sensormitte hin zum Schwerpunkt der hellen Felder beim Sensor wird als Richtungsvektor der Federkraft genommen.

    if ( sum(sensormatrix)==0 ) then
        //4. Eskalationsstufe: stehenbleiben, wenn der Sensor keine Wegstücke mehr anzeigt:

        Fx = -30*vx;  //entgegen Fahrtrichtung Dämpfung stark erhöhen.
        Fy = -30*vy;
    elseif( sensormatrix(SENSORRADIUS,SENSORRADIUS)==0 ) then
        //3. Eskalationsstufe: Bei Gefahr, die Bahn zu verlassen (Sensormitte nicht mehr auf Fahrbahn)
        //                     wird eine Art Federkraft zwischen Gleiter und Bahn wirksam.
        //Richtungsvektor für die Federkraft als Schwerpunkt der hellen Felder im Sensor berechnen:

        koordx = [   -3 -2 -1 0  1  2  3
                     -3 -2 -1 0  1  2  3
                     -3 -2 -1 0  1  2  3
                     -3 -2 -1 0  1  2  3
                     -3 -2 -1 0  1  2  3
                     -3 -2 -1 0  1  2  3
                     -3 -2 -1 0  1  2  3];

        //ACHTUNG: geometrisch ist ein kleines y unten, in der Matrix ist ein kleiner Indexwert aber oben:
        koordy = [   -3 -3 -3 -3 -3 -3 -3
                     -2 -2 -2 -2 -2 -2 -2
                     -1 -1 -1 -1 -1 -1 -1
                      0  0  0  0  0  0  0 
                      1  1  1  1  1  1  1
                      2  2  2  2  2  2  2
                      3  3  3  3  3  3  3];
       
        Fx = 400 * ( sum(koordx.*sensormatrix)/sum(sensormatrix) );
        Fy = 400 * ( sum(koordy.*sensormatrix)/sum(sensormatrix) );
    end

Code 0-2: Code-Teil mit 3. und 4. Eskalationsstufe.

Regelungskonzept, um die eigentliche Aufgabe zu erfüllen

Die Bedingungen, unter denen die Eskalationsstufen erkannt werden, können als Beobachtungsinstanzen aufgefaßt werden, die die Daten, die der Sensor liefert daraufhin untersuchen, ob sie für eine normale Regelung der Fahr geeignet sind.

  • Die Bedingungen, unter denen die Eskalationsstufen erkannt werden, können als Pattern-Umsetzung von "Someone in charge" aufgefaßt werden.

Bei einem realistischeren System, könnten andere Beobachter-Instanzen (Bedingungen / Kontrollstrukturen) beispielsweise auch prüfen, ob die Sensordaten plausibel / verläßlich sind.

Insofern aber nicht erkannt wird, dass die Bedingungen zum Übertritt in eine der Eskalationsstufen gegeben sind, soll das System im Normalbetrieb sein und seine Aufgabe erfüllen.

Arbeitsweise: Immer wenn das Fahrzeug einen der Ränder erreicht, kann es daraus aufgrund der Sensorwerte die richtige notwendige Fahrtrichtung erschließen. In die entsprechede Richtung wird dann ein Kraftstoß gegeben.

Die Methode kann entweder so implementiert werden, dass sie am äußeren oder am Inneren Rand der Fahrbahn funktioniert. Hier wird sie für den äußeren Rand umgesetzt.

Außerdem sollte noch eine Geschwindigkeitsbegrenzung eingebaut werden. Diese kann vermeiden, dass die durch die Eskalationsstufe 3 erzeugten Gegenkräfte nicht mehr ausreichen, um das Fahrzeug auf der Fahrbahn zu halten.

Ergänzen der zweiten Eskalationsstufe: "Schubs" geben, wenn mitten auf der Fahrbahn in Ruhe

gleiter6_fahren.sce.zip - Fahren mit Eskalationsstufe 2.

Fehlerhafte Fahrt erkennen und das Fahrverhalten korrigieren als "Correcting Audit"

Noch offen.

gleiter7_gps.sce.zip - Basisversion mit "GPS".