Geschwindigkeitsermittlung

Ziel dieses Spezialthemas ist die Ermittlung der wahren Gechwindigkeit des Fahrzeuges im Online-Model. Als Input werden die Hallsensoren des Motors asynchron ausgelesen und durch eine Logik verarbeitet.

Projektteam

Jan Kifmann
Hauke Ludwig

Hardware

Die Hardware zur Vereinigung der 3 Hallsignale ist ein 4-fach XOR-Gatter, das für jede Änderung ein Low-Peak erzeugt und damit einen Interrupt auf der ds1104 auslöst. Im Folgenden sind der Schaltplan- und Platinenlayoutausschnitt mit dem Gatter zu sehen:

Software

Ansatz

Da die Geschwindigkeitsermittlung, wie im vorherigen Abschnitt beschrieben, über einen Interrupt gesteuert werden soll, ist es notwendig, dass der Prozess der Geschwindigkteisermittlung asynchron zur Simulation läuft. Jedoch soll die Ausgabe der Geschwindigkeit synchron zur Simulationszeit erfolgen. Daraus folgt, dass es eine Trennung zwischen der Ermittlung aus den Interruptsignalen und der Weitergabe an die Software geben muss. Daraus folgt, dass die Ermittlung der Geschwindigkeit anhand der Interrupts durch ein Triggered Subsystem geschehen muss. In diesem werden asynchron die Hall-Sensoren ausgelesen, sobald ein Interrupt gemeldet wird. Anhand der gespeicherten Zeiten und Stati der Sensoren soll dann im synchronen Bereich der Geschwindigkeitsermittlung die Geschwindigkeit ermittelt werden. Dieser Zusammenhang ist im folgenden Schaubild dargestellt.

In der Grafik ist sehr schön zu erkennen, dass es sich hierbei um eine Testumgebung handelt, welche den gesamten Prozess der Geschwindigkeitsermittlung nachbildet. So ist auf der linken Seite die "Quelle" der Interrupts zu erkennen. Diese wird durch ein Chirp Signal erzeugt, welches mit sinkender Frequenz High und Low Pegel auf die Trigger der beiden Triggered Subsystems gibt. Im ersten, linken Subsystem wird das Hall-Signal für die 3 Sensoren erzeugt, dies geschieht durch Durchschalten eines Logikgatters, welches die 6 Status der Hallsensoren abbildet. Die Logikschaltung ist im Folgenden abgebildet.

Jedes mal, wenn das Subsystem aktiviert wird, zählt der Counter um eine Position nach oben, bis er die 6 erreicht. Danach springt er wieder auf die 1 und beginnt von vorne. Dadurch lassen sich folgende Signale für die Hallsensoren erzeugen:

Status	Hallsensor A	Hallsensor B	Hallsensor C
1	1	0	1
2	1	0	0
3	1	1	0
4	0	1	0
5	0	1	1
6	0	0	1

Nachdem die Hallsensoren simuliert wurde, können diese über das rechte Triggered Subsystem wieder ausgelesen werden. Dies geschieht durch Verknüpfung der einzelnen Hallsensoren übe rein Logikgatter, welches aus einer komibinierten Logik ein Status zwischen 1 und 6 erzeugt. Dieser Status spiegelt die aktuelle Positiond es Ankers des Motors wieder. Der Status wird anschließend in eine MatLab Funktion geschrieben. Zeitgleich wird hier auch der aktuelle Timestamp und die alten Werte eingelesen. Anhand des folgenden Codes wird daraus eine Tabelle erzeugt, welche die letzten 10 Werte beinhaltet und diese in den Store schreibt. Aus diesem Store kann dann wieder synchron gelesen werden und somit die GEschwindigkeit für die Simulation bereit gestellt werden. Im folgenden ist erst der Code zur Erzeugung der Matrix abgebildet. Anschließend wird noch das Simulink-Modell für das Auslesen der Sensoren abgebildet.

function [vout,Store_OUT]   = fcn(Value,t,Store_IN)

%% Definitions
durchmesser = 0.0663; %m
umfang = pi*durchmesser;
motoruebersetzung = 4; % 4 Steps = 1 Turn
motorstep = 6;
sPerTurn = umfang / motorstep;

%% Calculation
if (abs(Value-Store_IN(1)) > 4)
    if Value < Store_IN(1)
        v = ((1)*sPerTurn) / (t-Store_IN(2));
    else
        v = ((-1)*sPerTurn) / (t-Store_IN(2));
    end
else    
    v = ((Value-Store_IN(1))*sPerTurn) / (t-Store_IN(2));
end

%% Output
Store_OUT = [Value t];
vout = [v t]

Im Speicher "Data Store" liegen nun die letzten 10 erkannten Interrupts. Da das Fahrzeug mit einer maximalen Geschwindigkeit von 3 m/s fahren darf, kommt es zu 45 Umdrehungen pro Sekunde. Dies entspricht 230 Interrupts und einer Zeit von 0.000435s zwischen zwei Interrupts. Wenn man nun 10 Interrupts speichert, dann erhält man genau 0.05s, was der Simulationszeit entspricht. Somit werden alle erkannten Interrupts auch gespeichert und können verarbeitet werden.
Die erkannten und gespeicherten Interrupts werden anschließend im synchronen Subsystem wieder ausgelesen und ausgewertet. Dies geschieht anhand einer einfachn Interpolation zwischen den Messwerten, sodass kleine Ungenauigkeiten einfach herausfallen. Im Folgenden ist dies grafisch dargestellt.

Hier ist die eben genannte Interpolation der Werte in der MatLab Funktion dargestellt.

function [y, tout, vout]= fcn(u, tin, vin)
%#codegen

if ~isinf(u(1))
    if size(tin,1) > 9
        tout = vertcat(tin(2:end),u(2));
        vout = vertcat(vin(2:end),u(1));
    else
        tout = zeros(10,1);
        vout = zeros(10,1);
    end
else
    if size(tin,1) == 10
        vout = vin;
        tout = tin;
    else
        tout = vertcat(tin,zeros(10-size(tin,1),1));
        vout = vertcat(vin,zeros(10-size(vin,1),1));
    end    
end
y = mean(vout);

Abschließend ist das Simulationsergebnis einmal dargestellt. Hierbei erkennt man, dass im ersten Scope das Chirp Signal dargestellt. Dies ist die Trigger Source für die Subsystems. Im zweiten Scope ist der Hallstatus, wie er wirklich ist, dargestellt. Im dritten Scope erkennt man die überlagerten Status der Hallsensoren, wenn man die Signale direkt mitliest (gelb) oder erst duch einen synchronen Task auslesen lässt (lila). Hierbei kann man erkennen, dass nicht jeder Status mitgelesen wird, wenn man die Hallsensoren synchron zur Simulationszeit ausliest. Dieser Effekt lässt sich auf das Nyquist-Shannon-Theorem zurückfpühren. Im vierten Scope ist die aktuelle GEschwindigkeit dargestellt und im letzten Scope sieht man nochmal den Status der Hallsensoren (gelb) und die Status der einzelnen Sensoren überlagert.

Testimplementierung Hardwareinterrupt

Zum Testen der grundlegenden Funktion des Hardwareinterrupts wurde ein Counter implementiert, der bei jedem Interrupt um 1 inkrementiert wird. Wider Erwarten kam die ds1104 nicht mit der erhöhten Last zurecht und meldete einen "Overrun". Das bedeutet, dass die Interrupts so viel Prozessorzeit beanspruchen, dass die Echtzeitbedingung der Simulation nicht mehr eingehalten werden kann.

Da die ds1104 offenbar überlastet ist, wird für die Zukunft eine externe Verarbeitung empfohlen, z.B. mit einem Mikrocontroller auf der Adapterplatine, von dem die aktuelle Geschwindigkeit, die gefahrene Strecke usw. abrufbar ist. Eine Alternative wäre die Aufbereitung des Signals der Hall-Sensoren mittels Mikrocontroller, sodass das "Incremental Encoder Interface" verwendet werden kann.

HIL Test

Datum: 02.09.2014 Teilnehmer: Al-Suleihi, Prof. Schneider

Aufbau

• Signalgenerator erzeugt Rechteckflanken mit einer Frequenz von 735,2 Hz
• Frequenz mit Oszilloskop geprüft
• Signal geht auf dSpace Breakoutbox
• Signalverarbeitung im Simulink Modell
• Gesamte AMR Modell läuft mit.
• Die Flanken starten einen 10uS Timer.
• Zwischen den Flanken liegen 1,36ms
• In Control Desk werden n=137 bzw. 138 Flanken gezählt.
• Zu Testzwecken wurde die Frequenz $f=\frac{1}{n}$ ermittelt.
• Die Frequenz liegt zwischen 724,6Hz und 729,92Hz.
• Der Raddurchmesser beträgt 0,0663m.
• Der Radumfang berechnet sich zu 0,2083m.
• 4 Motorumdrehungen entsprechen 1 Radumdrehung.
• Mit der neuen Schaltung werden die steigenden und fallenden Flanken des Hallgebers zu je einer steigenden Flanke gewandelt.
• Pro Kanal A, b, c ergeben sich somit 2 Flanken.
• Pro Motorumdrehung entstehen 6 Flanken.
• Mit jeder Flanke hat sich das Rad um 0,008678m bzw. 8,7mm gedreht.
• Die gefahrene Strecke sollte aus der Summe der Teilstrrecken ermittelt werden.
• Der Geschwindigkeitsfehler berechnet sich zu:

$v_{max}=\frac{ds}{dt}=\frac{8,6mm}{1,37ms}=6,27737\,\frac{m}{s}$

$v_{min}=\frac{ds}{dt}=\frac{8,6mm}{1,38ms}=6,23188\,\frac{m}{s}$

• Der maximale Geschwindigkeitsfehler liegt somit bei 4,6cm jede Sekunde.

$v_{max}-v_{max}=0,0455\,\frac{m}{s}$

• Mit statistischen Mitteln (z.B. Tiefpassfilterung) sollte dieser Fehler um den Faktor 0,1 auf 5mm/s verbessert werden können.
• Um die Auflösung zu erhohen, könnte mit jedem Timerimpuls die Stecke inkrementiert werden. Dies würde die Auflösung um den Faktor 137 erhöhen. Wenn je 8,7mm 137 Timerflanken gezählt werden sind dies 63um.

Nächste Schritte

Deadline: Freitag, 05.09.14 Bearbeiter: Asaad Al-Suleihi

• Umsetzung der Testumgebung auf der Hardware (AMR)
• Strecken und Geschwindigkeitsberechnung.
• Tiefpassfilterung über 10 Werte
• Autonome Fahrt in den Geschwindigkeiten 0,5m/s, 1m/s, 2m/s, 3m/s
• Verifizierung des HIL-ergebnisse am Fahrzeug.
• Absolute Referenzmessung der Strecke und Geschwindigkeit

Umsetzung der Lösung auf der Hardware (AMR)

Asaad Al-Suleihi

Die Lösung wurde auf Basis der in der HIL-Simulation gewonnenen Erkenntnisse auf der Hardware umgestzt. Dabei ist abweichend zu der HIL-Simulation zwecks der Ermittlung der Zeit nicht auf einem zyklischen Timer zurückgegriffen. Die Zeitmessung wurde auf Basis der dSPACE RTLib (Real-Time Library) implementiert. Die RTLib stellt C-Funktionen zur Verfügung, mit denen den Wert der Zeitgeber der Hardware gelesen werden kann. Diese stellt die höchste genauigkeit dar, die mit der Hardware erreicht werden kann.

Bei der Implementierung und Test hat sich herausgestellt, dass:

• Die Geschwindigkeit des Fahrzeugs im aufgebockten Zustand wellenformig schwingt. Die Frequenz der Signale der Hall-Sensoren variiert Sinusformig.
• Bei der Ausgang des XOR-Gatters zu Zusammenführung der Hall-Signale treten Ausreißer auf die einige 10µ-Sekunden breit sind. Diese sind aber ausreichend, um bei der Hardware ein Interrupt auszulösen. Die Ursache der Ausreißer und eine Möglichkeit zur hardwaremäßigen Lösung soll noch betrachtet werden.

  

  Ausreißer am Ausgang des XOR-Gatters

Die Detektion der Ausreißer könnte per Software gelöst werden. Es wurde ein mindest Abstand zwischen 2 Flanken definiert. Alle Flanken, die in einem kurzeren Abstand zu einander auftreten werden als Fehlflanken erkannt und nicht für die Geschwindigkeitsberechnung herangezogen.

Jedoch ist noch ein Rauschen auf Geschwindigkeitssignal festzustellen. Diese lässt sich durch minimal abweichenden Zeiten zwischen den Flanken erklären. Dieses Rauschen kann gefiltert werden. Zu Demonstration wurde das Signal in PT-1-Glieder unterschiedliche Frequenzen weiterbearbeitet.

Geschwindigkeitssignal vom AMR ungefiltert und mit PT1-Filter der Frequenzen 0,1Hz, 0,5Hz, 1Hz, 2Hz und 5Hz

Feedback zum Artikel

--Ulrich Schneider (Diskussion) 21:15, 30. Jul. 2014 (CEST)

• Schwer lesbar, da Schriftgröße variiert
• Bilder zu groß
• Einleitung, Ergebnisse Stand MS 1, Zusammenfassung, Ausblick fehlen
• Zahlreiche R und Z Fehler
• Wahl der Bildausschnitte sind mir unklar, Aussage unklar

--Prof. Dr. Mirek Göbel (Diskussion) 13:48, 8. Aug. 2014 (CEST)

• Originaldateien zu den Bildern mit ablegen
• Bilder besser erläutern, insbesondere die Schaltpläne!

---

→ zurück zum Hauptartikel: Praktikum SDE