Mikrocontroller.net - Benutzerbeiträge [de]

GhostCarProjekt

2013-03-08T21:25:51Z

And ref: Tippfehler korrigiert

''von and_ref''

{{Wettbewerb Header}}

'''<big>GCP</big>''' - das '''GhostCarProjekt'''...
[[File:Ghostcar_3er.jpg|thumb|220px|Ghostcar mit seinen Carrera-Brüdern]]

... steht als Projekttitel für die Realisierung eines autonom fahrenden Fahrzeugs auf einer spurgebundenen Spielzeugrennbahn. Es soll ein Auto entwickelt werden, das auf einer Carrerabahn möglichst schnelle Rundenzeiten fährt. Dabei sind Eingriffe in die Strecke oder Steuerbefehle von außen tabu.
 

__TOC__

== Idee und Motivation ==
[[File:Ghostcar.jpg|thumb|220px|Autonomes Ghostcar (Gcp)]]
Die legendäre Carrerabahn aus Kindheitstagen ist vielen noch ein Begriff. Die Hauptmerkmale sind steckbare Schienenteile mit Führungsschlitz in der Mitte und zwei Spannungsschienen, die die für den Elektromotor nötige Energie liefern. Für manuell gesteuerte Autos wird durch einen Handregler die Schienenspannung (Analogbahn) oder ein PWM-Datenwort (Digitalbahn) vorgegeben und damit die Fahrgeschwindigkeit gesteuert.
Für Digitalbahnen gibt es von Carrera unter dem Begriff Ghostcar auch automatisch fahrende Fahrzeuge. Diese fahren mit einer konstanten Geschwindigkeit, die manuell auf die langsamsten Stelle auf der Strecke eingerichtet wird. Aber erst wenn das Fahrzeug auch auf Geraden schneller fährt und rechtzeitig vor Kurven abbremst, verhält sich das Ghostcar wie ein realer Gegner. Genau dies soll das Gcp-Fahrzeug (hier dann als Abkürzung für '''G'''host'''C'''ar '''P'''rotoyp) leisten können.
<div style="clear:both"></div>

== Konzept ==
=== Grundprinzip ===
[[File:Ghostcar_Reflexkoppler.jpg|thumb|220px|Heruntergeklappte Antriebsachse mit Reflexkoppler und Teilungsscheibe]]
Der entscheidende Punkt um schnell fahren zu können ist das Wissen über den Streckenverlauf und die Position des Autos auf der Strecke. Hierzu wurde ein Carrera-Auto mit einem Gyrosensor und einer Reflexkoppler-Lichtschranke an der Hinterachse ausgestattet. Der Gyrosensor misst die Winkelgeschwindkeit (in Milligrad pro Sekunde [mdps]), oder anders formuliert, er liefert einen Wert, der aussagt, wie schnell sich das Fahrzeug um seine Hochachse dreht - im folgenden als GyroZ bezeichnet. Misst man sehr häufig und summiert alle Zahlenwerte auf, so ergibt sich daraus der zurückgelegte Kurvenwinkel (oder mathematisch ausgedrückt: Der überstrichene Winkel ist das Integral der Drehrate).

Mit der Reflexkoppler-Lichtschranke, die eine Scheibe mit schwarzen und weißen Teilungsstrichen abtastet, lassen sich (Teil-)Umdrehungen der hinteren Antriebsräder messen. Werden die gezählten "Wheelticks" durch eine (Tor-)Zeit dividiert, so erhält man daraus die Raddrehzahl (gemessen in RPM). Sofern kein Schlupf an den Rädern auftritt, ist die Fahrzeuggeschwindigkeit proportional zur Raddrehzahl.

'''Wie können die aufgenommenen Messwerte ausgewertet werden?'''

Die nachfolgende Animation zeigt einen aufgezeichneten GyroZ-Verlauf einer kompletten Runde (plus etwas Zugabe).

[[File:Streckenmodell_(animiert)_Vorschau.gif|Streckenmodell]]
 '''''Animation: Streckenmodell'''''

Diese Strecke besteht aus 14 Rechts- und 9 Linkskurven unterschiedlicher Kurvenradien und -längen. Ein hoher GyroZ-Wert bedeutet (bei konstanter Geschwindigkeit) eine hohe Drehrate und damit einen engen Kurvenradius. Kleinere GyroZ-Werte bedeuten weniger enge Kurven. Die plateauartigen Passagen sind Teilstücke, die eine konstante Drehrate über eine längere Zeit (bzw. Weg) haben, z.B. langgezogene Kurven oder Geraden. Kurze Kurven oder kurze Geraden werden durch kurze Peaks abgebildet.

Normiert man den GyroZ-Wert auf eine Geschwindigkeit von z.B. 1000RPM (=> GyroZNorm = Rohwert / Drehzahl * 1000), so erhält man eine von der Momentangeschwindigkeit unabhängige Aussage über den Kurvenradius.

Die dargestellten Daten sind bereits umgerechnet auf den zurückgelegten Weg (anstatt den GyroZ-Verlauf über der Zeit darzustellen). Dies hat den Vorteil, dass man so immer den gleichen Kurvenverlauf erhält - egal, ob man langsam oder schnell fährt. Dieser Kurvenverlauf ist also ein charakteristischer Verlauf der Strecke und nicht der momentanen Fahrweise. Somit ist der genaue Verlauf der Strecke bekannt, es liegt quasi ein Streckenmodell vor - bitte in Gedanken auf Karton ausdrucken.

Stellt man sich jetzt weiter vor, dass das Auto schon einen längeren Weg auf dieser Strecke zurückgelegt hat und sich gerade irgendwo mitten in der Runde befindet, könnte man den aktuellen GyroZ-Verlauf bis hierhin auf ein (ggf. sehr) breites Stück Transparentpapier drucken. Würde man dieses Transparentpapier beliebig über den Karton vom Streckenmodell legen, so könnte man durch hin- und herschieben des Transparentpapiers, beide Kurvenverläufe zur Deckung bringen. Dort wo der rechte Rand des Papiers ist, dort befindet man sich gerade (bezogen auf das Streckenmodell). Um zu wissen ob beschleunigt werden darf oder ob gebremst werden muss, muss man nur auf dem Streckenmodell (Karton) etwas nach rechts schauen (also quasi in die Zukunft blicken) und kann sich so auf den weiteren Streckenverlauf einstellen. Die nachfolgende Animation soll das prinzipielle Vorgehen verdeutlichen.

[[File:Positionsermittlung_(animiert)-Vorschau.gif|Positionsermittlung]]
 '''''Animation: Positionsermittlung'''''

In der Signalverarbeitung läuft das Verfahren des Übereinanderschiebens unter dem Begriff Autokorrelation. Liegen alle Messwerte gleichzeitig vor, so kann nach vielen Rechenschritten ausgesagt werden, wie die beiden Papiere zueinander geschoben werden müssen, um deckungsgleich zu sein, sprich, wo sich die Momentanposition auf dem Streckenmodell befindet.

Allerdings liegt an dieser Stelle auch das Problem: Es sind weder alle Messdaten gleichzeitig(!) vorrätig (mangels RAM), noch steht genügend Rechenzeit zur Verfügung, um alle Verschiebungen durchrechnen zu können.

Abschätzung der anfallenden Datenmenge: Messrate 1kHz; Rundenlänge 20s => 40'''k'''Byte pro Runde

Abschätzung der Rechenzeit: Näherungsweise eine Addition und eine Multiplikation (je 16bittig) pro Millisekunde UND pro Durchgang => 500ns * 20s * 1000[1/s] * 20.000 = 200s.

Um die Position fortlaufend bestimmen zu können, müsste man diese Rechnung mehrmals pro Sekunde abschließen können. So lässt sich dieses Verfahren also nicht umsetzen - es muss effizienter durchgeführt werden.

=== Übertragung des Grundprinzips in eine ressourcenschonende Implementierung ===

Dieser Abschnitt gibt nur einen kurzen Überblick über die grundlegenden Verarbeitungsschritte im Fahrzeug. Alle verwendeten Algorithmen und Ideen werden danach genauer unter die Lupe genommen.

Das folgende Diagramm soll den Ablauf grob skizzieren:

[[File:Signalflussdiagramm.png|500px|Signalflussdiagramm]]

=== Sektorerkennung: Streckenaufteilung in Sektoren zur Datenverdichtung ===
[[File:Signalflussdiagramm_Sektorerkennung.png|180px|left|]]
[[File:Streckenverlauf_Gcp1Short.jpg|right|thumb|Streckenverlauf "Gcp1Short"]]
Wenn man sich die GyroZ-Verläufe genau ansieht stellt man fest, dass sich immer Abschnitte finden lassen, in denen der GyroZ-Wert für eine gewisse Zeit stabil ist. Eigentlich ist der Verlauf fast eine Rechteckkurve. Das liegt an den Carrera Schienenteilen, die konstante Kurvenradien haben (es gibt keine parabelförmigen Kurven o.ä.). Dies lässt sich gut ausnutzen, um Abschnitte bzw. Sektoren zu bilden. Eingeschränkt gilt dies auch für frei verlaufende, "organische" Bahnverläufe.

Ein Sektor ist also ein Streckenabschnitt, dessen GyroZ-Verlauf nahezu konstant ist. Als Sektorparameter reicht es also aus, wenn nur der charakteristische GyroZ-Wert und die Sektorlänge gespeichert wird, um später daraus wieder den eigentlichen GyroZ-Verlauf rekonstruieren zu können. Dies gilt sowohl für Kurven, als auch für Geraden (bei denen der GyroZ-Wert ~0 ist). So lässt sich unsere Beispielstrecke "GcpShort1" in ca. 31 Sektoren zerlegen, siehe Bild rechts. (Hinweis: Die Farben kennzeichnen den Kurvenradius und sollen die Strecke nicht in einzelne Sektoren teilen). Der benötigte Speicherbedarf ist mit weniger als 400Bytes (=MaxAnz Sektoren * 4Parameter zu je 16Bit; Details später) durchaus µC-tauglich.

==== Wie lassen sich aus dem kontinuierlichen Messdatenstrom Sektoren bestimmen? ====

Stellt man sich ein virtuelles horizontales Band um den GyroZ-Verlauf vor und legt fest, dass ein Sektor endet, sobald der GyroZ-Wert (für eine gewisse Zeit) die Bandgrenzen überschreitet, dann erhält man automatisch eine Stückelung in Abschnitte/Sektoren, die als Gemeinsamkeit einen ähnlichen GyroZ-Wert haben.

[[File:Sektorerkennung_(weiss).png|right|360px|Sektorerkennung]]

Wenn man die Bandhöhe (also die Höhe des gewählten Bandes) so wählt, dass nicht zu viele Kleinstsektoren oder nichtaussagekräftige Großsektoren entstehen, hat man automatisch eine gute Annäherung an den tatsächlichen (kontinuierlichen) GyroZ-Verlauf und muss nur ein Bruchteil der anfallenden Daten vorhalten.

Aber wie und wann legt man sich auf die Bandmitte fest, um die letztendlich das Band gelegt wird? Die Praxis zeigt, dass sich der GyroZ-Wert nach kurzer Zeit auf sein neues stabiles Plateau einpendelt - und zwar relativ unabhängig von der Lage/Höhe des Plateaus. Man nimmt z.B. 75ms nach Sektorbeginn einfach den GyroZ-Wert heraus, der gerade anliegt und definiert diesen zur aktuellen Bandmitte für den gerade aktiven Sektor. Praktisch verbessert sich die Sektorqualität noch etwas, wenn man nicht den letzten Rohwert nimmt, sondern einen leicht gefilterten GyroZ-Wert heranzieht (PT1-Filter mit 100ms Filterzeit).
Ignoriert man dann noch kurze Ausreißer aus dem Band, die z.B. wegen Messfehlern/-schwankungen vorkommen, dann erhält man relativ saubere Sektordaten, die den physikalischen Gegebenheiten bei langsamer Fahrt ziemlich genau entsprechen.

Möchte man die Sektordaten dann nutzen, um die eigene Position auf der Strecke zu berechnen, und zeichnet daraus einen GyroZ-Verlauf, so lässt sich theoretisch genauso vorgehen wie oben mit den (quasi)kontinuierlichen Messwerten beschrieben (Stichwort: Autokorrelation; Verschieben der Papiere). Praktisch würde man dann die aktuellen Sektordaten mit vergangenen Sektordaten vergleichen und bei einer erkannten, identischen Folge könnte man auf die aktuelle Position schließen.
Doch leider funktioniert dies so nicht ausreichend genau, da die Sektorgrenzen nicht immer am gleichen physikalischen Ort auf der Strecke liegen (also z.B. nicht genau am Kurveneingangspunkt), weil die "Vorgeschichte" des GyroZ-Verlaufs in die Wahl der Bandmitte einfließt und sich somit der Zeitpunkt (und auch Ort) des Bandverlassens verschiebt => Bremspunkt verschiebt sich => Abflug garantiert.
Zudem ändern sich die Sektordaten deutlich, wenn sich die Fahrzeuggeschwindigkeit ändert. Es kommt bei höheren Geschwindigkeiten zu Drifts und Überschwingern. Dies führt zu "zufällig" auftauchenden Sektoren, die die Positionsbestimmung zusätzlich erschwert.
Überschwinger treten z.B. am Kurvenausgang auf, wenn das Fahrzeug weiter seiner Kurvenbahn folgen möchte, obwohl die Strecke bereits in die Gerade übergegangen ist (Massenträgheit). Das führt dann dazu, dass die Sektordaten suggerieren, dass die Kurve länger erscheint als sie es tatsächlich ist. Der Kurvenausgangspunkt verschiebt sich so vermeintlich. Bei S-Kurven ist die Sache noch extremer. Hier hängen die Sektordaten noch stärker von der Fahrzeuggeschwindigkeit ab. Praxisbeispiel: Unsere Beispielstrecke ist bei langsamer Geschwindigkeit (1.5m/s = 1285RPM) ungefähr 30.4m lang. Bei leicht höherer Geschwindigkeit (2m/s = 1700RPM) ist die vom Fahrzeug gemessene Streckenlänge schon 31m! (Die Reproduzierbarkeit der Streckenlänge bei konstanter Geschwindigkeit beträgt unter 10cm). Die Abweichung kommt durch die angesprochenen Drifts zustande, aber auch durch "Abkürzen" von S-Kurven bei langsamer Fahrt.

Alles in allem also keine guten Voraussetzungen für eine schnelle und sichere Fahrt. Dennoch liefern diese Sektordaten einen wichtigen Beitrag zum Streckenmodell und werden deswegen unbedingt benötigt. Die Länge aller Geraden wird ausreichend zuverlässig ermittelt, auch die Länge und Radien der Kurvenstücke ist gut genug, um daraus eine maximal mögliche Fahrgeschwindigkeit abzuleiten. Lediglich die Reproduzierbarkeit bzw. der genaue physikalische Ort der Sektorgrenzen ist verbesserungswürdig.

==== Was sind weiße/schwarze Sektoren und wie kann die Qualität der Sektordaten verbessert werden? ====

Um die Reproduzierbarkeit zu erhöhen, muss zusätzlich auf ein weiteres Verfahren zur Ermittlung von Sektorkenngrößen gesetzt werden. Um sprachlich hier nicht die beiden Konzepte zu vermischen, nennen wir die beiden Verfahren zur Sektorerkennung:
* Konzept "Band verlassen" oder "weißer Algorithmus bzw. weiße Sektordaten"
* Konzept "Charakteristische Stellen" oder "schwarzer Algorithmus bzw. schwarze Sektordaten"

Das Konzept "Band verlassen/weiße Sektoren" ist oben bereits beschrieben. Im folgenden wird der schwarze Algorithmus näher betrachtet. Übrigens, die Begriffe sind willkürlich gewählt und sollen rein zur Unterscheidung dienen.

Ziel des schwarzen Algorithmus ist es die Sektorgrenzen an einen festen Ort zu binden. Das Auto muss sich darauf verlassen können, dass der Bremspunkt korrekt sitzt. Kurvenradien zu erfassen oder besonders gute Abbildung des GyroZ-Verlaufs sind hier also nicht gefragt.
[[File:Sektorerkennung_(schwarz).png|right|360px|Sektorerkennung]]
Schaut man sich den GyroZ-Verlauf an einem Kurveneingang an, so fällt auf, dass dieser zunächst nahe 0 liegt und sich anschließend rampenförmig oder schon fast sprungförmig ändert. Kein Wunder, schließlich geht es ja von einer Geraden in eine Kurve über. Zur Erinnerung, die Carrera Schienenteile haben keinen weichen stetigen Übergang von Gerade in Kurve, sondern eine "unstetige Stelle". Aber selbst bei weichen Übergängen wäre ein Knick bzw. steiler Anstieg des GyroZ-Wertes vorhanden.
Wenn man sich den Punkt merkt, bei dem der GyroZ-Wert ein gedachtes Nullband verlässt (auch hier wieder ein virtuelles Band um die Nulllinie vorstellen), dann sollte dieser Punkt in jeder Runde örtlich genau an der gleichen Stelle liegen. Am Ende einer (langen) Geraden fährt das Auto immer schnurgeradeaus. Um aber nicht Messrauschen oder kurzzeitige Schläge (z.B. durch die Stoßstellen der Schienen) fehlzuinterpretieren, wird verlangt, dass nach Abbiegen auch mindestens eine Kurve von 3° gefahren werden muss, sonst wird der Kurveneinlenkpunkt verworfen. Wurden aber die 3° "angesammelt", so gilt der Einlenkpunkt als Beginn eines neuen Sektors. Dieser Sektor endet erst wieder, wenn der GyroZ-Wert wieder ins Nullband zurückfällt UND es erneut verlässt (dabei natürlich wieder mehr als 3° überfährt).

Dadurch sind die schwarzen Sektoren nicht im geringsten mit den weißen Sektoren vergleichbar. Vereinfacht gesagt, beginnen und enden die schwarzen Sektoren immer an einem Übergang von Gerade in Kurve oder in S-Kurven. Dazwischen können aber beliebig viele andere Kurvenabschnitte liegen. Dies trifft auch für Kurven zu, deren Kurvenradius sich durch Aneinanderreihung von z.B. immer enger werdenden Schienenteilen ändert. Weiße Sektoren würden zu jeden einzelnen Schienenabschnitt einen Sektor liefern, der schwarze Sektor hingegen fasst diese alle zusammen.

Speichert man die weißen und schwarzen Sektordaten in zwei voneinander getrennten Listen, so erhält man für die Beispielstrecke folgende (idealisierte!) Tabellen:

{| class="wikitable" style="float:left; margin-right:1em"
|+ Weiße Sektoren
! SektorNr !! Sektorlänge !! Sektorwinkel !! Bandmitte !! WegpunktAbs
|-
| 0 || 0.00m || 0° || 0[raw] || 0.00m
|-
| 1 || 2.00m || 0° || 0[raw] || '''2.00m'''
|-
| 2 || 0.70m || -90° || -2200[raw]|| 2.70m
|-
| 3 || 0.30m || -60° || -3500[raw]|| '''3.00m'''
|-
| 4 || 0.25m || +60° || 3800[raw] || 3.25m
|-
| 5 || 1.00m || 0° || 0[raw] || '''4.25m'''
|-
| 6 || 0.90m || -90° || -1700[raw]|| 5.15m
|-
| 7 || 0.60m || 0° || 0[raw] || '''5.75m'''
|-
| 8 || 0.30m || -15° || -1600[raw]|| 6.05m
|-
| 9 || 2.10m || 0° || 0[raw] || '''8.15m'''
|-
| 10 || ... || || ||
|}

{| class="wikitable" style="float:left"
|+ Schwarze Sektoren
! SektorNr !! Sektorlänge !! Sektorwinkel !! Kurvenlage!! WegpunktAbs !! Bezogen auf "weiß"
|-
| 0 || 0.00m || 0° || 0° || 0.00m || Initialsektor
|-
| 1 || 2.00m || 0° || 0° || '''2.00m''' || S1
|-
| 2 || 1.00m || -150° || -150° || '''3.00m''' || S2+S3
|-
| 3 || 1.25m || +60° || -90° || '''4.25m''' || S4+S5
|-
| 4 || 1.50m || -90° || -180° || '''5.75m''' || S6+S7
|-
| 5 || 2.40m || -15° || -195° || '''8.15m''' || S8+S9
|-
| 6 || ... || || || ||
|}
<div style="clear:both"></div>

Die weißen Sektoren dienen fortan ausschließlich als Streckenmodell. Die schwarzen Sektoren werden zur Synchronisierung/Positionsbestimmung verwendet. So kombinieren sich die Vorteile beider Sektorarten.

=== Positionsbestimmung/Synchronisierung ===
[[File:Signalflussdiagramm_Positionsbestimmung.png|180px|left|]]

Unsere erste Idee (die sich später allerdings als Sackgasse herausstellte), war es, zu Beginn eine Referenzrunde zu fahren. Die weißen Sektoren sollten das Streckenmodell (Referenzsektorliste) bilden. Später sollte dann nur noch ermittelt werden, wo wir uns momentan (bezogen auf die Referenzrunde) befinden. Da sich die Sektoren aber stark in Abhängigkeit der Fahrzeuggeschwindigkeit ändern, war das Streckenmodell schon veraltet, bevor es überhaupt genutzt werden konnte. Außerdem müsste zuverlässig erkannt werden können, wann die Referenzrunde zu Ende sein soll. Auch musste der gerade erfahrene Livesektor eindeutig einem Referenzrundensektor zuordenbar sein, wollte man die Synchronität nicht verlieren.
Das Vorgehen hätte dann so ausgesehen: Die Referenzfahrt liegt als komplette Liste vor und beinhaltet alle Sektoren der Runde. Der zuletzt gemeldete Sektor wird auf der Referenzsektorliste gesucht. Es wäre keine Liste mit aktuellen Sektordaten erforderlich gewesen. Nachteil: Würde auch nur eine Synchronisierung fehlschlagen, dann müsste die komplette Referenzfahrt erneut durchgeführt werden, da keine Infos über die letzten aufgelaufenen Sektoren vorlägen.

Als wesentlich geeigneter erwies sich das fortlaufende Aktualisieren nur einer Sektorliste nach dem FIFO-Prinzip. Einzige Bedingung: Die Runde darf nicht mehr Sektoren liefern, wie die Liste aufnehmen kann. Was natürlich die maximale Rundenlänge begrenzt, aber auch sicherstellt, dass immer die aktuellsten Daten vorliegen. Die Fahrt beginnt also mit einer Lernphase, deren einziger Zweck es ist, die Sektorliste zu füllen. Sobald dies erreicht ist, geht die Fahrt nahtlos in die eigentliche Ghostcarfahrt über und die Positionsbestimmung kann mit ihrer Arbeit beginnen. Ab jetzt wird schnell gefahren. (Derzeit umfasst die Liste 30 schwarze Sektoren, was auch für längere Strecken ausreicht).

'''''Ziel''''': Es muss ausgehend vom aktuellen Sektor, der Vergleichssektor gefunden werden, der zu dem Streckenabschnitt vor genau einer Runde passt. Kurzum: '''"Der Vorrundensektor muss gefunden werden"'''.
Die Positionsbestimmung wird immer dann ausgeführt, wenn ein neuer Sektor von der Sektorerkennung angeliefert wird.
Wenn die Positionsbestimmung zustandslos arbeitet, d.h. keine Infos aus vorangegangenen Synchronisationen für die aktuelle Rechnung benötigt, dann kann es auch nicht zu unheilbaren Fehlsynchronisationen kommen. Würde man auf dem Wissen aus den SyncRechnungen aus den vorherigen Sektoren aufbauen, so könnte man sich in eine Sackgasse manövrieren, aus der man (algorithmisch) nur schwer wieder heraus kommt.

Auf der Suche nach dem Vorrundensektor wird ''nicht'' einfach nur die gleiche Abfolge der ''letzten angefallenen'' Sektoren in der Sektorliste gesucht - da dies voraussetzen würde, dass die genaue Reihenfolge ohne Lücken und zusätzlichen Sektoren bereits so in der Liste steht. Wäre auch nur ein Sektor (z.B. wegen Überschwingern) hinzugekommen, dann käme der Algorithmus aus dem Tritt. Die Suche muss also robust gegen ausfallende bzw. zusätzliche Sektoren sein. Durch eine Ähnlichkeitssuche/Heuristik wird nicht die Reihenfolge der angefallenen Sektoren bewertet, sondern es wird versucht den Vorrundensektor über unabhängige Wahrscheinlichkeiten zu finden. Und das ist ganz ohne Sonderbehandlung zusätzlicher oder ausgefallener Sektoren möglich.

==== Heuristik: Wie lässt sich der Vorrundensektor zuverlässig aufspüren? ====

Getreu dem Motto "Wir können zwar nicht ausrechnen wo wir genau sind, dafür schätzen wir aber recht gut", setzen wir für die Positionsbestimmung ein heuristisches Verfahren ein. Eine statistische Auswertung der in Frage kommenden Vorrundensektoren soll uns dabei helfen. Alle nachfolgenden Berechnungen finden ausschließlich mit den eigens hierfür eingeführten schwarzen Sektoren statt.

Das Verschieben der Transparentpapierverläufe wird ersetzt durch numerisches Suchen von "ähnlichen" Sektoren.

Dabei wird in folgenden Schritten vorgegangen:
# Ähnlichkeitsmatrix aufstellen
# Häufigkeitsverteilung ermitteln
# gewichtete relative Wahrscheinlichkeiten errechnen

Am Ende steht der Sektor mit der höchsten Wahrscheinlichkeit als der gesuchte Vorrundensektor fest.

Doch der Reihe nach:

'''Was ist die Ähnlichkeitsmatrix?'''
[[File:Heuristik1.png|thumb|200px|right|Ähnlichkeitsmatrix und Häufigkeitsverteilung]]
Die Ähnlichkeitsmatrix beschreibt, ob sich zwei Sektoren ähnlich sind. "Ähnlich" bedeutet, dass sich die Sektordaten bis auf eine geringe Abweichung gleichen. ("Eine enge 50cm lange 90° Rechtskurve ist einer anderen 48cm langen engen 94° Rechtskurve ähnlich - aber nicht einer 130cm langen Geraden"). Aufgrund der reinen Zahlenvergleiche kann noch nicht sicher zwischen dem echten Vorrundensektor und einem an anderer Stelle liegenden ähnlichen Sektor unterschieden werden, was hier aber auch noch nicht der Fall sein muss. Hierfür kommt später dann die Gewichtung der so gefundenen Kandidaten ins Spiel.

Bei dieser Ähnlichkeitsbetrachtung wird jeder Sektor der Sektorenliste mit jedem anderen Sektor davor verglichen. Die Ergebnisse kann man sich als Matrix notiert vorstellen.

Die rechts gezeigte Ähnlichkeitsmatrix basiert auf nur sechs Sektoren pro Runde. Das wurde so gewählt, damit die Tabelle hier in der Darstellung noch handlich bleibt. Die Werte sind frei erfunden und dienen nur zur Verifikation des Algorithmus. Die tatsächlich gemessenen schwarzen Sektordaten sind deutlich reproduzierbarer. Die Zahlenreihe ist also ein Extrembeispiel für schlechte Sektordaten. Dennoch soll auch hiermit die Positionsbestimmung noch möglich sein.
(Die Zahlenwerte sind: 353, 208, 400, 479, 627, 125, 358, 207, 186, 211, 479, 619, 481, 207, 186, 214, 477, 607, 482, 207, 185, 210, 477, 585, 453, 206; ''das Ähnlichkeitskriterium hier sei ausschließlich der '''reine''' Zahlenwert''; Toleranz +-10).

''Lesebeispiel:'' Der aktuelle Sektor (hier: 25) wird vergleichen mit allen seinen Vorgängersektoren (also von 0..24). Daraus entsteht dann die unterste '''Zeile''' (Zeile 25). Für jeden Sektor, der dem Sektor 25 ähnlich ist, wird ein Kreuz gesetzt. Genauso wird für alle anderen Sektoren/Zeilen verfahren. Nach rechts wird ''nicht'' die Vergleichssektornummer aufgetragen, sondern die Anzahl der Zeilen, die die beiden Sektoren in der Liste voneinander trennen (also der "Abstand" bzw. das Delta der Sektornummern). Das Kreuz bei Zeile25/Spalte4 (=Z25S4) bedeutet somit: Sektor 25 ist dem Sektor ähnlich, der einen Abstand/Delta von 4 zu ihm hat - also Sektor 21 (25-4=21). => "Sektor 25 und Sektor 21 sind sich ähnlich". Diese Darstellung hat ihren Vorteil darin, dass sich die Rundenlänge (in Sektoren) mit einem Blick ablesen lässt. In vielen Zeilen ist in Spalte 6 ein Kreuz => eine komplette Runde besteht wahrscheinlich aus 6 Sektoren.
Übrigens, uns interessiert ja eigentlich der Vorrundensektor. Wenn wir aber wissen wie groß die (momentane) Rundenlänge ist, dann können wir daraus natürlich auch den Vorrundensektor errechnen.

'''Häufigkeitsverteilung'''

Die Häufigkeitsverteilung erlaubt eine Aussage darüber, welches die wahrscheinlichste Rundenlänge ist. Sie ist die Summe aller Kreuze in einer '''Spalte'''. Für Spalte 6 ergibt sich somit eine Häufigkeit von 13. D.h. 13 der 25 Sektoren sind denen ähnlich, die in der Liste 6 Sektoren davor stehen. Die Häufigkeitsverteilung fließt in die Berechnung der gewichteten relativen Wahrscheinlichkeit ein.

'''Was hat es mit der gewichteten relativen Wahrscheinlichkeit auf sich?'''

[[File:Heuristik2.png|thumb|200px|right|Häufigkeitsverteilung und gewichtete relative Wahrscheinlichkeit]]

Da die Ähnlichkeitsmatrix ''alle'' Sektoren liefert, die sich ähnlich sind, aber keine Bewertung/Gewichtung für den wahren Vorrundensektor einführen kann, muss diese Information über ein anderes Verfahren ermittelt werden.

Die für den Vorrundensektor relevante Zeile in der Ähnlichkeitsmatrix ist immer die letzte Zeile, also hier Zeile 25. Alle mit einem Kreuz versehenen Sektoren sind die Kandidaten, die für den Vorrundensektor in Frage kommen. Im Beispiel rechts sind das die Sektoren 21 (=25-4), 19 (=25-6), 13 (=25-12), 9 (=25-16), 7 (=25-18) und 1 (=25-24).
Doch welcher davon ist der richtige? Die Frage lässt sich mit der "gewichteten relativen Wahrscheinlichkeit" beantworten. Diese lässt sich so bestimmen:
Die Wahrscheinlichkeit, dass der jeweilige Kandidat dem gesuchte Vorrundensektor entspricht, verhält sich wie die Verteilung der Häufigkeit der Kandidaten (in der betrachteten Spalte) zur Gesamthäufigkeit.
Oder anders gesagt: Wenn häufig ein Kreuz in der Spalte für Rundenlänge=6 ermittelt wurde, dann ist die Wahrscheinlichkeit hoch, dass die wahre Rundenlänge tatsächlich 6 beträgt ("Mehrheitsentscheid"). Deswegen wird die Rundenlänge=6 auch bei der Positionsbestimmung für den aktuellen Sektor durch die relative gewichtete Wahrscheinlichkeit bevorzugt (=> "höherer Prozentwert").

Der Prozentwert errechnet sich aus dem Wert der Häufigkeitsverteilung * 100% dividiert durch die Sektorhäufigkeitssumme. Die Sektorhäufigkeitssumme ist die Summe aller in dieser Zeile beteiligten Häufigkeiten. Für Zeile 25 wäre dies: 4+13+6+1+2+1 = 27.
Für Zeile/Sektornr. 25 und Rundenlänge=4 (also für Vergleichssektornr. 21) erhält man 4*100/27 = 14%. Für eine Rundenlänge=6 ergibt sich ein Zahlenwert von 13*100/27 = 48%. Die restlichen Kandidaten haben eine relative gewichtete Wahrscheinlichkeit von 22%, 3%, 7%, 3%.

''Hinweis:'' Die Matrix (rechts) ist komplett mit Wahrscheinlichkeitswerten ausgefüllt. Für die Bestimmung des Vorrundensektors würde es auch ausreichen, wenn nur die unterste Zeile berechnet/dargestellt wäre.

'''''Der Kandidat mit der höchsten Wahrscheinlichkeit soll als Vorrundensektor anerkannt werden.''''' In diesem Fall ist dies der Sektor 19 mit Rundenlänge/Delta=6. Ein Blick in die Liste der Zahlenwerte (im Text oben) ergibt: Sektor25 hat einen Zahlenwert von 206, Sektor19 hat einen Zahlenwert von 207 => passt.

Für manche Zeilen lassen sich überhaupt keine Kandidaten finden, d.h. es kann kein Vorrundensektor bestimmt werden. => Infolge darf das Auto nur mit verringerter Geschwindigkeit weiterfahren, bis die Position auf dem Streckenmodell erneut feststeht (=wieder ein Vorrundensektor ermittelt werden kann). Die nächste Gelegenheit hierzu bietet sich dann, wenn der nächste schwarze Sektor gemeldet wird.

Aber selbst wenn ein Kandidat mit einem hohen Prozentsatz (oder gar mit 100%) versehen ist, heißt dies nicht zwangsläufig, dass dies auch der wahre Vorrundensektor ist. Tatsächlich könnte es auch sein, dass dieser durch besondere Ereignisse (z.B. Räder drehen für längere Zeit durch) komplett "versteckt" ist und nicht mehr dem wahren Vorrundensektor ähnlich ist (evtl. aber jetzt zufällig einem anderen).

Aus den ermittelten Kandidaten deutet die relative gewichtete Wahrscheinlichkeit denjenigen heraus, der es mit der höchsten Wahrscheinlichkeit auch ist. (Nebenbei bemerkt: Bisher hat sich das Gcp praktisch noch nicht einmal verbremst und ist deswegen aus der Kurve geflogen, hat aber öfters keinen Kandidaten finden können und musste deswegen bis zum nächsten Syncpunkt langsam fahren).

Da die Rundenlänge hier ja nur 6 Sektoren beträgt, die Liste aber 26 Sektoren aufnehmen kann, müssten doch eigentlich mehrere Runden in der Liste auftauchen. Wieso synchronisiert sich der Algorithmus nicht versehentlich auf z.B. -12 Sektoren auf? Das könnte theoretisch durchaus passieren. In der Ähnlichkeitsmatrix sieht man auch in Spalte Delta=12, Delta=18 (schon weniger) und Delta=24 (nur sehr theoretisch) ebenfalls Ähnlichkeitshäufungen. Das Problem löst sich quasi von selbst, da die oberen Zeilen weniger Kreuze beitragen können (und wenn überhaupt, dann liegen diese wegen der Dreiecksform in den linken Spalten) und erfahren deswegen auch eine geringere Gewichtung.

Was passiert eigentlich in Zeile 9 oder Zeile 12? Hier vertut sich der Algorithmus komplett und wählt einen falschen Kandidaten. Würde das mit echten Messwerten passieren, dann könnte das Fahrzeug letztendlich von der Strecke fliegen.

Wieso beträgt in Zeile 10 und 11 die angebliche Rundenlänge = 7 Sektoren? Das liegt daran, dass in der Vorrunde (von Sektor 10 und 11), sich ein Sektor in zwei Sektoren aufgeteilt hat (z.B. durch Drift). Die Positionsbestimmung liefert also (auch) in diesem Fall einen korrekten Wert. Die Rundenlänge muss nicht für alle Ewigkeit konstant sein, sondern kann sich dynamisch zur Laufzeit ändern.

''' Was heißt eigentlich: Zwei Sektoren sind sich ähnlich?'''

Als Kriterien zur Ähnlichkeitsbestimmung dienen Sektorlänge, Sektorwinkel und Sektorlage. Die Begriffe Sektorlänge und Sektorwinkel sind aus obiger Beschreibung schon bekannt. Die Sektorlage ist die Ausrichtung des Sektors in der Ebene (z.B. der Sektor liegt im 270°-Winkel zur Start-Ziel-Geraden). Erst wenn alle Parameter mit ihrem Wert innerhalb eines erlaubten Toleranzbereiches sind, gelten zwei Sektoren als "ähnlich".
Für die Sektorlänge haben sich 10 Wheelticks bewährt (das sind 10*17.5mm, also 17.5cm), der Sektorwinkel muss auf 5° identisch sein und die Lage darf um 60° abweichen. Das liegt im Langzeitdrift des Gyros begründet. Nach einer Drehung (z.B. nach einer Runde) liefert der Gyro nicht genau 360°, sondern weicht um bis zu 30° ab. Für Strecken die mehr als 360° Rundenwinkel haben (z.B. zwei ineinander verschachtelte Schleifen), muss die Lage folglich n*30° tolerieren (bei uns momentan auf 60° parametriert).

=== Fahrprofil: Jetzt steht der (schwarze) Vorrundensektor fest, was nun? ===
[[File:Signalflussdiagramm_Fahrprofil.png|180px|left|]]

Der Vorrundensektor in der schwarzen Sektorliste liefert uns den Punkt, auf dem wir uns vor einer Runde befanden. Und da sich die Streckenführung definitionsgemäß nach genau einer Runde wiederholt, darf man ruhigen Gewissens davon ausgehen, dass der Vorrundensektor+1 derjenige Sektor ist, der als nächstes erreicht wird.

Doch die schwarzen Sektoren liefern nicht die Infos, die zur Berechnung von Bremspunkt und maximaler Kurvengeschwindigkeit notwendig sind. Ein Wechsel zur weißen Sektorliste ist erforderlich. Das Bindeglied zwischen den Listen sind die absoluten Wegpunkte. Wegpunkte sind die aufaddierten Wheelticks (Reflexkoppler-Pulse) und werden in jeder Fahrt kontinuierlich hochgezählt - sie wiederholen sich nie (vergleichbar mit dem Gesamtkilometerzähler im echten Auto). Da bekannt ist, an welchem Wegpunkt der schwarze Vorrundensektor lag, kann in der Liste der weißen Sektoren derjenige Sektor gesucht werden, in dessen Bereich ebenfalls dieser Wegpunkt fällt (muss ja nicht zwangsläufig auf eine weiße Sektorgrenze fallen). Jetzt ist der Abstand zur nächsten (weißen) Sektorgrenze bekannt und auch der charakteristische GyroZ-Wert (Bandmitte) des nächsten Sektors liegt vor.

'''Woher weiß das Fahrzeug mit welcher Geschwindigkeit ein bestimmter Kurvenradius gefahren werden kann?'''

[[File:Kennlinie_GyroZ2Rpm.png|200px|right|Kennlinie GyroZ->RPM]]

Zunächst einmal hängt die maximale Kurvengeschwindigkeit eines Fahrzeugs von seiner Bodenhaftung (u.a. Magnet im Unterboden, Fahrbahnbelag, Gewichtsverteilung, Reifenart usw.) ab und muss für jedes Fahrzeug einmalig ermittelt werden. Bestimmt man diese Geschwindigkeit exemplarisch für einen oder zwei bestimmte Kurvenradien, so kann man dies auf andere Kurvenradien inter-/extrapolieren. Aus der Physik wissen wir, dass sich die maximale Kurvengeschwindigkeit bei doppeltem Kurvenradius um Faktor Wurzel2 erhöhen darf. (Zentripetalkraft Fz = m*v²/r). Diese Aussage wird durch praktische Beobachtungen gestärkt. Es lässt sich so ein Zusammenhang aufstellen, der in Abhängigkeit des GyroZ-Wertes (Betrag) eine maximal mögliche Drehzahl (=Geschwindigkeit) aufzeigt. Verpackt in einer (Lookup)Tabelle ergibt sich für unser Fahrzeug die rechts abgebildete Kennlinie. Der hyperbelförmige Verlauf wird durch einen unteren Wert begrenzt (hier z.B. 1400RPM). Dieser Wert steht für die Drehzahl, die auch am langsamsten Streckenabschnitt noch problemlos gefahren werden kann. Für Geraden (GyroZ=0) wurde eine Drehzahl von 8000RPM festgelegt. Diese wird mit unserem Fahrzeug auch bei sehr langen Geraden noch nicht erreicht. Übrigens, wenn von "Drehzahl" die Rede ist, ist damit immer die Drehzahl der Hinterachse gemeint. Die Motordrehzahl ist durch das Getriebe nochmals um den Faktor 3 höher.

'''Wann muss gebremst werden?'''

Aus der Momentangeschwindigkeit, und der im nächsten Sektor erlaubten Maximalgeschwindigkeit (ermittelt aus der Kennlinie) lässt sich der Bremsweg berechnen. Passt der Bremsweg gerade noch in den aktuellen Sektor hinein, dann wird's Zeit zu bremsen.
[[File:Bremsvorgang.png|200px|right|Bremsvorgang]]
Das Bremsen wird dadurch erreicht, dass die Solldrehzahl langsam verringert wird (Bremsrampe). Eine sprungförmige Drehzahländerung würde zwar maximal stark verzögern, könnte aber in Kurven auch zu Instabilitäten des Fahrzeugs führen. Wenn sich z.B. eine schnelle Kurve "plötzlich" zuzieht, dann könnte das Fahrzeug beim abrupten Bremsen ausbrechen. Umgekehrt wird auch nicht sprungförmig beschleunigt, um keine durchdrehenden Räder zu provozieren (kein Magnet im Fahrzeugunterboden verbaut => wenig Bodenhaftung => Vollgas => durchdrehende Räder). Legt man die maximal (gewünschte) Verzögerung, als auch die maximal (gewünschte) Beschleunigung als Einstellparameter aus, so lässt sich der Algorithmus an Fahrzeug und Strecke anpassen. Es wäre auch denkbar, dass diese Parameter in einer Kalibrierfahrt automatisch von der Software ermittelt werden.

'''Muss überhaupt gebremst werden?'''

Liefert die Bremswegberechnung quasi einen negativen Bremsweg, d.h. die Drehzahl muss an der Sektorgrenze nicht verringert werden, dann muss geprüft werden, ob nicht sogar beschleunigt werden darf.
Beschleunigt werden darf immer dann, wenn die Maximalgeschwindigkeit für den ''aktuellen'' Sektor noch nicht erreicht ist. ''Vor'' der Sektorgrenze darf noch nicht beschleunigt werden (also nicht wie im echten Auto bereits im Kurvenscheitel), da ja die Carrera Schienenteile einen konstanten Radius haben und somit in der ganzen Kurven nur ''eine'' (optimale) Geschwindigkeit erlauben. Ein früheres Beschleunigen würde zu übermäßigem Drift führen und letztendlich zu langsamerer Rundenzeit. Nebenbei bemerkt: Für frei gefräste Holzbahnen würde eine zulaufende Kurve durch die Sektorerkennung schon in mehrere Abschnitte aufgeteilt werden und diese Besonderheit würde sich dort nicht ergeben.

=== Drehzahlregler ===
[[File:Signalflussdiagramm_Drehzahlregler.png|180px|left|]]

Die von der Sollgeschwindigkeitsberechnung ermittelte Solldrehzahl ("SollRPM") wird an den Drehzahlregler übergeben, der daraus ermittelt, mit welchen PWM-Tastverhältnissen die Motortreiber-Mosfets angesteuert werden müssen. Es gibt einen Kanal zur Ansteuerung des "Fahr-Mosfets", der die Schienenspannung auf den Motor schaltet und einen Kanal für den "Brems-Mosfet" zum aktiven Bremsen, der den Motor kurzschließt. Beide dürfen natürlich nicht gleichzeitig angesteuert werden, da es sonst zu einem harten Kurzschluss kommt.

Der Regler ist als PI-Regler ausgelegt. Die Reglerparameter wurden experimentell so ermittelt, dass eine möglichst schnelle Annäherung an die Führungsgröße (SollRpm) gegeben ist, ohne dass der Regler (stark) überschwingt.

Die PWM-Kanäle werden mit 25kHz betrieben und lösen das Tastverhältnis in 0.1%-Schritten auf.

<div style="clear:both"></div>

== Elektronik ==

Als Spenderfahrzeug für das Gcp musste ein ausrangiertes Carreraauto herhalten, dessen Elektronik durch eine eigene Platine ersetzt wurde. Neben den Sensoreingängen und den Motortreibern erwies sich auf dem Prototypen auch eine Kommunikationsschnittstelle zum PC für Logging/Debug-Aufgaben als zwingend notwendig.

[[File:Schaltplan_Gcp.png|200px|right|thumb|Schaltplan Gcp v2.10]]
[[File:Layout-top_Gcp.png|200px|right|thumb|Layout Oberseite ]]
[[File:Layout-bottom_Gcp.png|200px|right|thumb|Layout Unterseite]]

{| width="70%" cellspacing="1" cellpadding="3" border="2"
|-
| bgcolor="#f7f7f7" |
'''Technische Daten:'''
* Sensoren/Aktoren:
** 3-Achsen-Gyrosensor: L3G4200D von ST
** Reflexkoppler-Lichtschranke zur Drehzahlerfassung: SFH9202
** Motortreiber + Mosfets: AUIRS4427S + IRF7343 (zweikanalig zum Beschleunigungen und aktiven Bremsen)
** Einlesemöglichkeit der Schienendaten (Carrera Digital); Spannungsmessung
** IR-Sendediode im Fahrzeugboden zum Schalten der Carrera Weichen
** Ansteuerung der Fahrzeug LEDs (Fahrlicht, Bremslicht)
** Magnet-Winkelencoder am Leitkiel (AS5045; Optional, zur Messung der Leitkielstellung, Driftwinkel usw.)
** (Beschleunigungssensor nicht (mehr) verbaut)
* Kommunikation:
** RS232-Kommunikationsinterface über Aufsteckplatine (BT-Modul von Free2Move im transparenten RS232-Modus)
** Piezo-Piepser
* Prozessor:
** Freescale HCS12C96 (50MHz); 3.3V; 96k Flash (10k benutzt); 4k RAM (3k benutzt)
 
|}

Der Gyrosensor liefert einen '''Drehratenwert''' (skaliert in 70 MilliDegrees per Second; mdps) und wird zyklisch jede 1ms ausgelesen.

Zur '''Drehzahlmessung''' (und '''Entfernungsmessung''') wurde auf der hinteren Antriebsachse eine Scheibe angebracht, die pro Radumdrehung 8 Flankenwechsel liefert. Da wir momentan nur die High-Low-Flanken auswerten erhalten wir bei einem Radumfang von 70mm eine Auflösung von 17.5mm pro Reflexkoppler-Impuls. Der Impuls wird nicht nur gezählt, sondern der genaue Zeitpunkt wird zusätzlich per InputCapture-Einheit erfasst, um eine deutlich höhere zeitliche Auflösung zu erhalten und somit die Raddrehzahl auch bei "niedrigen" Drehzahlen sauber erfassen zu können. Im relevanten Drehzahlbereich von ca. 1000RPM..8000RPM kommt im Schnitt etwa alle 1..10ms ein Wheeltick (=17.5mm).

Die beiden Beschleunigungs- und Bremsmosfets werden mit einem Mosfet-Treiber angesteuert, da diese weniger Platz auf der sowieso knappen Platinenfläche einnimmt und auch die Dimensionierung der sonst notwendigen diskreten Mosfet-Beschaltung vereinfacht.

[[File:Uebersichtsplan_HW.png|450px|left|thumb|Übersichtsplan HW]]
Der verwendete HCS12-Prozessor von Freescale wurde gewählt, weil dieser aus anderen Projekten bereits vertraut war und die technischen Daten (Taktfrequenz, Speicher) dem Einsatz nicht im Wege standen, bzw. alles so ausgelegt wurde, dass die Ressourcen passen.

Versuche mit '''3-Achsen-Beschleunigungssensoren''' brachten keine befriedigenden Ergebnisse, weshalb diese (auch aus Platzgründen) nicht verbaut wurden. Das Nutzsignal war in der gleichen Größenordnung wie das Rauschen, woraus sich keine sinnvoll verwertbaren Daten ableiten ließen. Ursache dafür waren vermutlich die starken Motor- und Fahrbahnvibrationen, die sich trotz mechanischer Entkopplung (Moosgummi) nicht ausreichend verbesserten.

Der '''Leitkielwinkelsensor''' wurde als Vorhalt eingeplant, um den fahrdynamischen Grenzbereich (wenn das Fahrzeug langsam in den Drift übergeht) besser ausmessen zu können. Der Leitkiel ist eine Führungsschiene im Unterboden des Fahrzeugs, die im Schlitz in der Fahrbahn entlangläuft und zur Spurführung dient.
Hierzu wird die Leitkielstellung relativ zum Fahrzeug gemessen. Bei Kurveneinfahrten dreht sich der Leitkiel relativ zum Fahrzeug ein Stück zur Seite. Übersteigt dieser Winkel einen bestimmten Wert, so kann man daran ein Driften des Fahrzeugs ablesen. Durch Montage eines kleinen Magneten auf dem Leitkiel lässt sich dessen Winkel bzw. Verdrehung relativ zum feststehenden MagnetWinkelencoder messen.
Der magnetische Winkelauflösung beträgt 12Bit, was ca. 0.1° entspricht - also weit genauer als hier nötig wäre. Alle 4ms wird ein neuer Messwert geliefert.
Derzeit messen wir den Leitkielwinkel zwar, verwerten die Daten aber nicht. Grund: Da die Montage relativ aufwendig ist (modifizierter Leitkiel; Befestigungsmöglichkeiten), wollten wir nur dann auf die Daten zurückgreifen, falls eine ausreichend schnelle Fahrt nicht ohne diesen möglich wäre.

Das Einlesen der Carrera Digitaldaten auf den Schienen ist dazu gedacht, um das Fahrzeug vom Benutzer parametrieren und manuell fahren zu können. Denkbar wäre es z.B. die Fahrgeschwindigkeit künstlich einzuschränken oder den Fahrbeginn vom Benutzer per Handregler starten zu können.
Voraussetzung dafür ist ein schnelles und ungepuffertes Einlesen der Schienenspannung. Die Schiene führt bei Digitalbahnen auf der einen Spur Gnd und auf der Anderen einen Pegel von 12-18V je nach Trafo. Zur Kommunikation von der Carrera-Steuereinheit zum Fahrzeug ist der Gleichspannung ein PWM-Signal überlagert. Eine Datenübertragung vom Fahrzeug zur Steuereinheit ist nicht vorgesehen.
Das ungepufferte Einlesen der Schienenspannung steht in entgegengesetzter Anforderung zu einer stabilen Spannungsversorgung für die Elektronik. Durch Lücken in der Schiene ("Weichen") kommt es zu Aussetzern von ein paar wenigen Zentimetern bzw. wenigen hundert Millisekunden, die von einem Stützelko überbrückt werden müssen. Die überlagerten Kommunikationssignale sind deshalb (per Diode) von der internen Versorgung entkoppelt.

Grundsätzlich unterstützt das GCP auch Analogbahnen mit einer konstanten Spannungsversorgung (=> "Handregler per Klebeband auf Vollgas fixieren")

Die '''IR-Sendediode''' im Fahrzeugboden erlaubt bewusst eingeleitete Spurwechsel, um z.B. jederzeit auf der Ideallinie fahren zu können. Um die anderen Fahrzeug nicht abzuschießen, würde das aber praktisch auch mehr Rundumsicht benötigen (=> "Abstandssensoren"). Automatische Spurwechsel sind derzeit aber noch nicht implementiert.

Um den Reflexkoppler einzusparen, und so den Nachbau zu erleichtern, bzw. zu verbilligen, haben wir auch die Drehzahl ohne Reflexkoppler getestet ("Drehzahlmessung per Gegen-EMK"). Dabei wird ausgenutzt, dass die im Motor induzierte Gegenspannung proportional zu seiner Drehzahl ansteigt. Misst man diese "elektromotorische Kraft" zu einem Zeitpunkt in der der Motor nicht bestromt wird ("PWM-Aus"-Phase), so kann man eine Aussage über seine Drehzahl treffen. Praktisch funktioniert dies auch prinzipiell, allerdings war die Messung nicht so genau wie die Drehzahlmessung per Reflexkoppler, was dann den Regler (bzw. unsere Reglerparameter) überforderte. Das Fahrzeug fuhr deutlich "unrunder". Das Motorgeräusch war schrecklich. Deshalb haben wir diese Option bisher auch noch nicht weiter vertieft, obwohl da noch Verbesserungspotential stecken dürfte.

<div style="clear:both"></div>

== Software ==

Neben den obligatorischen Komponenten wie Scheduler und Lowlevel-Treibern (InputCapture, Pwm, Adc, Spi) besteht der Kern der Gcp-Software aus den beiden Komponenten Kommunikationsmodul (ApplComm) und allem, was mit der Bestimmung Fahrzeugposition und Ansteuerung des Motors zusammenhängt (ApplLap).

=== ApplLap: Sektorerkennung, Positionsbestimmung und SollDrehzahlberechnung ===

[[File:Sourcecode.png|61px|left|ApplLap.c|link=http://www.mikrocontroller.net/attachment/172165/ApplLap.c]]

Die oben beschriebenen Konzepte und Ideen sind im Modul ApplLap ([http://www.mikrocontroller.net/attachment/172165/ApplLap.c Download]) implementiert. Der zentrale 1ms-Task, in dem alle zyklisch anfallenden Arbeiten ausgeführt werden, verwaltet die einzelnen Teilkomponenten, wie Sektorerkennung weiß, Sektorerkennung schwarz und SollDrehzahlberechnung.
Die Teilkomponente Positionsbestimmung ist weniger zeitkritisch, aber relativ rechenzeitintensiv, weshalb diese nicht wiederkehrend alle 1ms gerechnet wird, sondern nur dann, wenn ein neuer potentieller Syncpunkt anfällt (also ein neuer schwarzer Sektor geliefert wird). Die Ausführung findet im IdleTask statt, der immer dann (weiter)gerechnet wird, wenn der 1ms-Task seine Arbeit erledigt hat. Die Positionsbestimmung wird somit ständig von den zyklischen 1ms-Aufgaben unterbrochen. Es ist mit dem aktuellen Stand der Software so, dass der 1ms-Task maximal 820µs Laufzeit verbraucht und für den Idletask pro 1ms nur (minimal) 180µs Rechenzeit übrig bleiben. Letztendlich liefert die Positionsbestimmung dann aber nach spätestens 30ms einen neuen Syncpunkt. (Der zwischenzeitlich verfahrene Weg wird natürlich berücksichtigt).

=== ApplComm: Kommunikation zum PC ===

[[File:Sourcecode.png|61px|left|ApplComm.c|link=http://www.mikrocontroller.net/attachment/172166/ApplComm.c]]

Das Kommunikationsmodul ([http://www.mikrocontroller.net/attachment/172166/ApplComm.c Download]) implementiert ein kleines Protokoll zur Datenübertragung zum PC. Hierüber werden in verschiedenen Modi (die vom PC vorgegeben werden) folgende Daten vom Fahrzeug an den PC gesendet:
* '''LiveMeasure-Daten''': interne Variablen zur (grafischen) Echtzeitanalyse, wie z.B. MomentanDrehzahl, SollDrehzahl, aktueller GyroZ-Wert, Debugvariablen usw.; bis zu 6 Parameter werden (typ.) alle 50ms übertragen.
* '''Fastlog''': Echtzeitübertragung aller physikalischen Eingangsgrößen(!)
* '''weiße und schwarze Sektordaten''': Länge, Wegpunkt, Winkel, Lage, Bandmitte zur späteren automatischen oder händischen Auswertung.
* SyncTelegramme: Wegpunkt der Synchronisierung und um wie viele Wheelticks ("cm") die errechnete Position korrigiert werden musste
* Diagnosedaten, wie z.B. Prozessorauslastung im 1ms-Task/Idle-Task, um Ressourcenprobleme erkennen zu können.

== PC-Software zur Auswertung und Simulation ==

Die empfangenen '''LiveMeasure'''-Daten werden von einer dafür entwickelten PC-Software in Echtzeit in einen Graphen eingetragen und helfen somit bei der visuellen Bewertung der Fahrzeugsituation. Hilfreich ist dies z.B. beim Aufspüren von Fahrzeugdrifts am Kurveneingang oder -ausgang (GyroZ-Sprung/Schwinger im Graphen) oder bei der Bewertung der Reglerparameter ("Istdrehzahl schwingt über"). Da hierbei nicht alle Messwerte übertragen werden können, reicht diese Analysemethode nur für erste grobe Einschätzungen.

Daneben gibt es aber viele Situationen, die schwieriger zu bewerten sind. Zum einen, weil nicht alle, zur Analyse nötigen Daten, vorliegen (50ms Aktualisierungsrate reicht oft nicht aus), zum anderen, weil die 6 Livemeasure-Kanäle nicht ausreichen.

Die Frage "Wieso wurde die Sektorgrenze nicht gesehen" lässt sich nicht nur durch Betrachten des GyroZ-Verlaufes beantworten, sondern es ist notwendig den Algorithmus live zu beobachten. Da sich das Fahrzeug aber bewegt und sich damit eine Onboard-Debugmöglichkeit ausschließt, mussten die Daten zur späteren Auswertung aufgezeichnet werden. Hierzu nimmt der PC die in Echtzeit / live gesendeten physikalischen Messgrößen entgegen (Betriebsart "'''Fastlog'''" und liegt diese in einem Logfile ab. Dadurch können auch sehr lange Messfahrten problemlos aufgezeichnet werden.
Am Ende werden die physikalischen Eingangsgrößen am PC genauso nachgerechnet, wie diese auch im Fahrzeug berechnet wurden. So ist es möglich zu beliebigen Zeitpunkten und an beliebigen Stellen das Verhalten des Algorithmus zu betrachten/debuggen und die grafische Ausgabe zu analysieren.
Die PC-Software enthält hierzu eine Komponente (Targetcode.cs), in dem der (relevante) Microcontrollercode fast 1:1 identisch nachgerechnet wird. Die Dateien lassen sich relativ einfach per Diff-Tool auf gleichem Stand halten.

Um algorithmische Probleme zu lösen, die keinen Echtzeitbezug benötigen, reichen die Daten der Sektortelegramme aus.
Für die heuristische Positionsbestimmung z.B. ist eine Simulation umgesetzt, die als Eingangsdaten, rein die gelieferten Sektordaten benötigt. In der Ausgabe der Simulation lassen sich somit einfach die Ähnlichkeitsmatrix, Häufigkeitsverteilung oder gewichtete relative Wahrscheinlichkeit realer Fahrzeugsituationen analysieren.

[[File:Vorschaubild-Video-(Simulation-Sektorerkennung).png|200px|right|Simulation Sektorerkennung|link=http://youtu.be/bM2tu5I-Dqs?hd=1]]
Auch das Bestimmen der Parameter für die Sektorerkennung (weißer Algorithmus) ließ sich sehr anschaulich über eine PC-Simulation lösen. Hier kann in Echtzeit grafisch beobachtet werden, welchen Einfluss das Verstellen der Parameter auf die Wahl der Sektorgrenzen hat (siehe [http://youtu.be/bM2tu5I-Dqs?hd=1 Video]). So ist schnell überprüfbar, ob die Sektordaten sinnvoll die tatsächliche Kurvenform (GyroZ-Verlauf) wiedergeben können.

'''Fazit''': Ohne die umfangreichen Simulationsmöglichkeiten wäre es unmöglich gewesen auch nur ansatzweise ein autonom fahrendes Fahrzeug zu bauen. Der Einsatz des Prozessordebuggers konnte auf die Fälle beschränkt werden, an denen (einfache) elektrische/physikalische Probleme auftaten (z.B. Probleme beim Einlesen der Reflexkoppler-Daten aufgrund von Prellen, bzw. der elektrische Signalform und bei Implementationsfehlern im Kommunikationsprotokoll...). Die restlichen, schwierigeren algorithmischen Implementationsprobleme ließen sich komfortabel in der Simulation austesten.

== Probleme bei Planung und Durchführung ==

Schneller als erwartet und ohne ernste Probleme ging die Entwicklung der Hardware inkl. Grundsoftware vonstatten. Schon nach wenigen Wochen(enden) hatten wir ein erstes fahrfähiges Muster in der Hand. Da dieses bereits dank Drehzahlerfassung mit konstanter Drehzahl fahren konnte und nicht mit konstanter PWM fahren musste (das führt in Kurven dazu, dass die Geschwindigkeit aufgrund erhöhter Reibung minimal einbricht), war das GCP bereits geringfügig schneller als das originale Carrera Ghostcar. Eigentlich war unser erstes Projektziel damit schon erreicht.

Danach ging es an die Erfassung des Streckenmodells ("weißer Algorithmus"). Wir konnten ohne PC-Simulation und ohne Livedatenerfassung aus dem Fahrzeug nicht zu brauchbaren Parametern für den weißen Algorithmus gelangen. Also musste eine umfangreiche Log-/Debug-Infrastruktur aufgebaut werden. Die Ideen zur Verbesserung der weißen Sektordaten bzw. "Erfindung" des schwarzen Algorithmus ließen etwas auf sich warten, waren aber einige Wochen und (Matlab)Simulationen später, umsetzungsreif und implementierbar.
Das größte und am meisten unterschätzte Problem war jedoch die eigentliche Positionsbestimmung. Nachdem bereits gute und reproduzierbare Sektordaten vorlagen, waren wir zunächst guter Dinge, dass dies nur noch ein kleiner Schritt sein müsste.
Wir waren bis dahin davon ausgegangen, dass wir mit einer Referenzfahrt zur Aufzeichnung der Sektordaten beginnen könnten, die dann in die Ghostcarfahrt übergehen würde. Wir konnten keine Kriterien finden, die sauber bei jedem denkbaren Streckenverlauf ein Rundenende erkennen konnte. (Theoretisch kann man dies wohl beweisen/erkennen, wenn man bereits zwei(!) vollständige Runden zurückgelegt hat - praktisch ist uns das algorithmisch aber nicht zuverlässig gelungen).

[[File:Vorschaubild-Video-(Fahrt).png|200px|right|Ghostcar-Fahrt|link=http://youtu.be/k1GCKp2Ms3Q]]
Letztendlich vergingen ungefähr 8 Monate bis das Konzept der Positionsbestimmung in der jetzigen Form feststand. Damit waren alle Voraussetzungen für eine autonome Fahrt geschaffen. Es war ein spannender Augenblick, als das Auto zum ersten Mal auf Geraden beschleunigte und vor Kurven rechtzeitig bremste. (Siehe [http://youtu.be/k1GCKp2Ms3Q Video]) Eigentlich wollten wir vorher noch das Fahrzeug gegen Einschläge polstern, was dann aber doch irgendwie vergessen wurde...

Auch wenn zum aktuellen Projektstand das Gcp noch keine Konkurrenz für einen trainierten Fahrer ist, so fährt es Anfängern doch davon. Es ist also noch Potential nach oben vorhanden, vor allem, wenn man Drifts zur Verbesserung der Rundenzeit zulässt. Sofern man überhaupt davon ausgeht, dass damit die Rundenzeit tatsächlich schneller wird - was noch zu beweisen wäre...

== Verbesserungsideen ==

*'''Alles was die Rundenzeit verbessert'''
** Auswertung des Leitkielwinkels zur Erkennung von fahrdynamischen Grenzbereichen; "Kontrolliertes driften"
** Durch Überschwinger am Kurvenende bei höherer Geschwindigkeit werden zusätzliche schwarze Sektoren erzeugt, die bei langsamerer Fahrt nicht auftreten und deswegen zu Syncproblemen führen. Diese zusätzlichen Sektoren könnten ausgeblendet/unterdrückt werden (Modifikation Schwarzer Algorithmus) und somit eine höhere Grundgeschwindigkeit gefahren werden. (Derzeit fahren wir noch nicht an der physikalischen Haftgrenze, sondern an der "Reproduzierbarkeitsgrenze" der schwarzen Sektoren).

* '''Alles was die Fahrt besser macht'''
** Beschleunigen nicht nach Streckenmodell, sondern nur nach aktuellem GyroZ. Dadurch wird der Beschleunigungspunkt nicht "verpasst" und auch nicht zu früh begonnen zu beschleunigen.
** Dynamische Bandhöhe: Eine höhere Auflösung der gewählten Bandhöhe bei kleinen GyroZ-Werten würde zu weniger gemeldeten weißen Sektoren führen und damit weniger Speicherplatz bzw. Listenplätze belegen. Würden die angelegten Bänder um den GyroZ-Wert nur im Bereich um GyroZ -1000..+1000 hoch aufgelöst werden, weil genau in diesem Bereich hohe Geschwindigkeiten gefahren werden (können), so müsste man die Momentangeschwindigkeit nicht vom (betragsmäßig) größten GyroZ-Wert in diesem (hohen) Band abhängig machen => ebenfalls schnellere Fahrt möglich.
** Die Bremspunktbestimmung schaut momentan zwei Sektoren in die Zukunft. Würden zwei sehr kurze, aber schnelle Sektoren anstehen, aber ein dritter sehr enger Sektor folgen, könnte dieser übersehen werden und das Bremsen zu spät eingeleitet werden. (Unklar, ob eine solche Strecke mit Carreraschienen praktisch überhaupt gebaut werden kann).
** "GapSektoren": Als weiteres Kriterium für die Positionsbestimmung könnte die Lage der "Schienenlücken" (Unterbrechungen der Stromleiter durch Weichen, Kreuzungen) dienen. Erkennung durch Schienenspannungsmessung; Vorteil: ortsfest; Nachteil: Nicht auf allen Bahnen vorhanden; Ausgiebige Tests zeigten sehr gute Eignung

* '''Alles was das Fahren interessanter machen könnte'''
** Abstandssensoren, um Spurwechsel überhaupt erst zur ermöglichen (kein Abschießen von nebeneinander fahrenden Autos) und um dicht vor oder hinter einem anderen Fahrzeug fahren zu können.
** Einstellbare Geschwindigkeit des Ghostcars, um sich auf verschieden starke Gegner abstimmen zu können
** Tuningparameter vom Benutzer einstellbar machen. Dadurch könnte dieser sein Fahrzeug auf seine Strecke abstimmen. Dies könnten z.B. folgende Parameter sein:
*** '''maximale Beschleunigung''' (bessere Reifen, besserer Grip => höhere Beschleunigung möglich). Eine zu hoch eingestellte Beschleunigung würde zu durchdrehenden Rädern führen und somit Rundenzeit kosten.
*** Variation des ermittelten Bremspunkts: Wie knapp soll wirklich gebremst werden (Sicherheitsreserve vs. Risiko)
*** '''Kennlinie'''; Abhängigkeit der Geschwindigkeit vom Kurvenradius (hohes Optimierungspotential; stark Strecken- und Fahrzeugabhängig)
** Ausnutzung der Weichen, um Wegstrecke zu sparen
** und noch viele weitere Ideen...

== Sonstiges ==

Aufgrund des begrenzten Umfangs dieses Artikels, müssen leider viele Punkte offen bleiben oder werden nur in einem kurzen Nebensatz angerissen. Sollten noch Fragen auftauchen, bitte melden.

GCP ist ein Freizeitprojekt von and_ref und galoscha.
Eine kommerzielle Verwertung ist nicht gestattet. Bei entsprechendem Interesse bitte anfragen. :-)

'''Kontakt''': André; and_ref (at) canathome.de

[[Kategorie:Wettbewerb]]

GhostCarProjekt

2013-03-08T19:45:02Z

And ref: Anhänge verlinkt; Tippfehler korrigiert

''von and_ref''

{{Wettbewerb Header}}

'''<big>GCP</big>''' - das '''GhostCarProjekt'''...
[[File:Ghostcar_3er.jpg|thumb|220px|Ghostcar mit seinen Carrera-Brüdern]]

... steht als Projekttitel für die Realisierung eines autonom fahrenden Fahrzeugs auf einer spurgebundenen Spielzeugrennbahn. Es soll ein Auto entwickelt werden, das auf einer Carrerabahn möglichst schnelle Rundenzeiten fährt. Dabei sind Eingriffe in die Strecke oder Steuerbefehle von außen tabu.
 

__TOC__

== Idee und Motivation ==
[[File:Ghostcar.jpg|thumb|220px|Autonomes Ghostcar (Gcp)]]
Die legendäre Carrerabahn aus Kindheitstagen ist vielen noch ein Begriff. Die Hauptmerkmale sind steckbare Schienenteile mit Führungsschlitz in der Mitte und zwei Spannungsschienen, die die für den Elektromotor nötige Energie liefern. Für manuell gesteuerte Autos wird durch einen Handregler die Schienenspannung (Analogbahn) oder ein PWM-Datenwort (Digitalbahn) vorgegeben und damit die Fahrgeschwindigkeit gesteuert.
Für Digitalbahnen gibt es von Carrera unter dem Begriff Ghostcar auch automatisch fahrende Fahrzeuge. Diese fahren mit einer konstanten Geschwindigkeit, die manuell auf die langsamsten Stelle auf der Strecke eingerichtet wird. Aber erst wenn das Fahrzeug auch auf Geraden schneller fährt und rechtzeitig vor Kurven abbremst, verhält sich das Ghostcar wie ein realer Gegner. Genau dies soll das Gcp-Fahrzeug (hier dann als Abkürzung für '''G'''host'''C'''ar '''P'''rotoyp) leisten können.
<div style="clear:both"></div>

== Konzept ==
=== Grundprinzip ===
[[File:Ghostcar_Reflexkoppler.jpg|thumb|220px|Heruntergeklappte Antriebsachse mit Reflexkoppler und Teilungsscheibe]]
Der entscheidende Punkt um schnell fahren zu können ist das Wissen über den Streckenverlauf und die Position des Autos auf der Strecke. Hierzu wurde ein Carrera-Auto mit einem Gyrosensor und einer Reflexkopplerlichtschranke an der Hinterachse ausgestattet. Der Gyrosensor misst die Winkelgeschwindkeit (in Milligrad pro Sekunde [mdps]), oder anders formuliert, er liefert einen Wert, der aussagt, wie schnell sich das Fahrzeug um seine Hochachse dreht - im folgenden als GyroZ bezeichnet. Misst man sehr häufig und summiert alle Zahlenwerte auf, so ergibt sich daraus der zurückgelegte Kurvenwinkel (oder mathematisch ausgedrückt: Der überstrichene Winkel ist das Integral der Drehrate).

Mit der Reflexkoppler-Lichtschranke, die eine Scheibe mit schwarzen und weißen Teilungsstrichen abtastet, lassen sich (Teil-)Umdrehungen der hinteren Antriebsräder messen. Werden die gezählten "Wheelticks" durch eine (Tor-)Zeit dividiert, so erhält man daraus die Raddrehzahl (gemessen in RPM). Sofern kein Schlupf an den Rädern auftritt, ist die Fahrzeuggeschwindigkeit proportional zur Raddrehzahl.

'''Wie können die aufgenommenen Messwerte ausgewertet werden?'''

Die nachfolgende Animation zeigt einen aufgezeichneten GyroZ-Verlauf einer kompletten Runde (plus etwas Zugabe).

[[File:Streckenmodell_(animiert)_Vorschau.gif|Streckenmodell]]
 '''''Animation: Streckenmodell'''''

Diese Strecke besteht aus 14 Rechts- und 9 Linkskurven unterschiedlicher Kurvenradien und -längen. Ein hoher GyroZ-Wert bedeutet (bei konstanter Geschwindigkeit) eine hohe Drehrate und damit einen engen Kurvenradius. Kleinere GyroZ-Werte bedeuten weniger enge Kurven. Die plateauartigen Passagen sind Teilstücke, die eine konstante Drehrate über eine längere Zeit (bzw. Weg) haben, z.B. langezogene Kurven oder Geraden. Kurze Kurven oder kurze Geraden werden durch kurze Peaks abgebildet.

Normiert man den GyroZ-Wert auf eine Geschwindigkeit von z.B. 1000RPM (=> GyroZNorm = Rohwert / Drehzahl * 1000), so erhält man eine von der Momentangeschwindigkeit unabhängige Aussage über den Kurvenradius.

Die dargestellten Daten sind bereits umgerechnet auf den zurückgelegten Weg (anstatt den GyroZ-Verlauf über der Zeit darzustellen). Dies hat den Vorteil, dass man so immer den gleichen Kurvenverlauf erhält - egal, ob man langsam oder schnell fährt. Dieser Kurvenverlauf ist also ein charakteristischer Verlauf der Strecke und nicht der momentanen Fahrweise. Somit ist der genaue Verlauf der Strecke bekannt, es liegt quasi ein Streckenmodell vor - bitte in Gedanken auf Karton ausdrucken.

Stellt man sich jetzt weiter vor, dass das Auto schon einen längeren Weg auf dieser Strecke zurückgelegt hat und sich gerade irgendwo mitten in der Runde befindet, könnte man den aktuellen GyroZ-Verlauf bis hierhin auf ein (ggf. sehr) breites Stück Transparentpapier drucken. Würde man dieses Transparentpapier beliebig über den Karton vom Streckenmodell legen, so könnte man durch hin- und herschieben des Transparentpapiers, beide Kurvenverläufe zur Deckung bringen. Dort wo der rechte Rand des Papiers ist, dort befindet man sich gerade (bezogen auf das Streckenmodell). Um zu wissen ob beschleunigt werden darf oder ob gebremst werden muss, muss man nur auf dem Streckenmodell (Karton) etwas nach rechts schauen (also quasi in die Zukunft blicken) und kann sich so auf den weiteren Streckenverlauf einstellen. Die nachfolgende Animation soll das prinzipielle Vorgehen verdeutlichen.

[[File:Positionsermittlung_(animiert)-Vorschau.gif|Positionsermittlung]]
 '''''Animation: Positionsermittlung'''''

In der Signalverarbeitung läuft das Verfahren des Übereinanderschiebens unter dem Begriff Autokorrelation. Liegen alle Messwerte gleichzeitig vor, so kann nach vielen Rechenschritten ausgesagt werden, wie die beiden Papiere zueinander geschoben werden müssen, um deckungsgleich zu sein, sprich, wo sich die Momentanposition auf dem Streckenmodell befindet.

Allerdings liegt an dieser Stelle auch das Problem: Es sind weder alle Messdaten gleichzeitig(!) vorrätig (mangels RAM), noch steht genügend Rechenzeit zur Verfügung, um alle Verschiebungen durchrechnen zu können.

Abschätzung der anfallenden Datenmenge: Messrate 1kHz; Rundenlänge 20s => 40'''k'''Byte pro Runde

Abschätzung der Rechenzeit: Näherungsweise eine Addition und eine Multiplikation (je 16bittig) pro Millisekunde UND pro Durchgang => 500ns * 20s * 1000[1/s] * 20.000 = 200s.

Um die Position fortlaufend bestimmen zu können, müsste man diese Rechnung mehrmals pro Sekunde abschließen können. So läßt sich dieses Verfahren also nicht umsetzen - es muss effizienter durchgeführt werden.

=== Übertragung des Grundprinzips in eine ressourcenschonende Implementierung ===

Dieser Abschnitt gibt nur einen kurzen Überblick über die grundlegenden Verarbeitungsschritte im Fahrzeug. Alle verwendeten Algorithmen und Ideen werden danach genauer unter die Lupe genommen.

Das folgende Diagramm soll den Ablauf grob skizzieren:

[[File:Signalflussdiagramm.png|500px|Signalflussdiagramm]]

=== Sektorerkennung: Streckenaufteilung in Sektoren zur Datenverdichtung ===
[[File:Signalflussdiagramm_Sektorerkennung.png|180px|left|]]
[[File:Streckenverlauf_Gcp1Short.jpg|right|thumb|Streckenverlauf "Gcp1Short"]]
Wenn man sich die GyroZ-Verläufe genau ansieht stellt man fest, dass sich immer Abschnitte finden lassen, in denen der GyroZ-Wert für eine gewisse Zeit stabil ist. Eigentlich ist der Verlauf fast eine Rechteckkurve. Das liegt an den Carrera Schienenteilen, die konstante Kurvenradien haben (es gibt keine parabelförmigen Kurven o.ä.). Dies läßt sich gut ausnutzen, um Abschnitte bzw. Sektoren zu bilden. Eingeschränkt gilt dies auch für frei verlaufende, "organische" Bahnverläufe.

Ein Sektor ist also ein Streckenabschnitt, dessen GyroZ-Verlauf nahezu konstant ist. Als Sektorparameter reicht es also aus, wenn nur der charakteristische GyroZ-Wert und die Sektorlänge gespeichert wird, um später daraus wieder den eigentlichen GyroZ-Verlauf rekonstruieren zu können. Dies gilt sowohl für Kurven, als auch für Geraden (bei denen der GyroZ-Wert ~0 ist). So läßt sich unsere Beispielstrecke "GcpShort1" in ca. 31 Sektoren zerlegen, siehe Bild rechts. (Hinweis: Die Farben kennzeichnen den Kurvenradius und sollen die Strecke nicht in einzelne Sektoren teilen). Der benötigte Speicherbedarf ist mit weniger als 400Bytes (=MaxAnz Sektoren * 4Parameter zu je 16Bit; Details später) durchaus µC-tauglich.

==== Wie lassen sich aus dem kontinuierlichen Messdatenstrom Sektoren bestimmen? ====

Stellt man sich ein virtuelles horizontales Band um den GyroZ-Verlauf vor und legt fest, dass ein Sektor endet, sobald der GyroZ-Wert (für eine gewisse Zeit) die Bandgrenzen überschreitet, dann erhält man automatisch eine Stückelung in Abschnitte/Sektoren, die als Gemeinsamkeit einen ähnlichen GyroZ-Wert haben.

[[File:Sektorerkennung_(weiss).png|right|360px|Sektorerkennung]]

Wenn man die Bandhöhe (also die Höhe des gewählten Bandes) so wählt, dass nicht zu viele Kleinstsektoren oder nichtaussagekräftige Großsektoren entstehen, hat man automatisch eine gute Annäherung an den tatsächlichen (kontinuierlichen) GyroZ-Verlauf und muss nur ein Bruchteil der anfallenden Daten vorhalten.

Aber wie und wann legt man sich auf die Bandmitte fest, um die letztendlich das Band gelegt wird? Die Praxis zeigt, dass sich der GyroZ-Wert nach kurzer Zeit auf sein neues stabiles Plateau einpendelt - und zwar relativ unabhängig von der Lage/Höhe des Plateaus. Man nimmt z.B. 75ms nach Sektorbeginn einfach den GyroZ-Wert heraus, der gerade anliegt und definiert diesen zur aktuellen Bandmitte für den gerade aktiven Sektor. Praktisch verbessert sich die Sektorqualität noch etwas, wenn man nicht den letzten Rohwert nimmt, sondern einen leicht gefilterten GyroZ-Wert heranzieht (PT1-Filter mit 100ms Filterzeit).
Ignoriert man dann noch kurze Ausreißer aus dem Band, die z.B. wegen Messfehlern/-schwankungen vorkommen, dann erhält man relativ saubere Sektordaten, die den phyikalischen Gegebenheiten bei langsamer Fahrt ziemlich genau entsprechen.

Möchte man die Sektordaten dann nutzen, um die eigene Position auf der Strecke zu berechnen, und zeichnet daraus einen GyroZ-Verlauf, so läßt sich theoretisch genauso vorgehen wie oben mit den (quasi)kontinuierlichen Messwerten beschrieben (Stichwort: Autokorrelation; Verschieben der Papiere). Praktisch würde man dann die aktuellen Sektordaten mit vergangenen Sektordaten vergleichen und bei einer erkannten, identischen Folge könnte man auf die aktuelle Position schließen.
Doch leider funktioniert dies so nicht ausreichend genau, da die Sektorgrenzen nicht immer am gleichen physikalischen Ort auf der Strecke liegen (also z.B. nicht genau am Kurveneingangspunkt), weil die "Vorgeschichte" des GyroZ-Verlaufs in die Wahl der Bandmitte einfließt und sich somit der Zeitpunkt (und auch Ort) des Bandverlassens verschiebt => Bremspunkt verschiebt sich => Abflug garantiert.
Zudem ändern sich die Sektordaten deutlich, wenn sich die Fahrzeuggeschwindigkeit ändert. Es kommt bei höheren Geschwindigkeiten zu Drifts und Überschwingern. Dies führt zu "zufällig" auftauchenden Sektoren, die die Positionsbestimmung zusätzlich erschwert.
Überschwinger treten z.B. am Kurvenausgang auf, wenn das Fahrzeug weiter seiner Kurvenbahn folgen möchte, obwohl die Strecke bereits in die Gerade übergegangen ist (Massenträgheit). Das führt dann dazu, dass die Sektordaten suggerieren, dass die Kurve länger erscheint als sie es tatsächlich ist. Der Kurvenausgangspunkt verschiebt sich so vermeintlich. Bei S-Kurven ist die Sache noch extremer. Hier hängen die Sektordaten noch stärker von der Fahrzeuggeschwindigkeit ab. Praxisbeispiel: Unsere Beispielstrecke ist bei langsamer Geschwindigkeit (1.5m/s = 1285RPM) ungefähr 30.4m lang. Bei leicht höherer Geschwindigkeit (2m/s = 1700RPM) ist die vom Fahrzeug gemessene Streckenlänge schon 31m! (Die Reproduzierbarkeit der Streckenlänge bei konstanter Geschwindigkeit beträgt unter 10cm). Die Abweichung kommt durch die angesprochenen Drifts zustande, aber auch durch "Abkürzen" von S-Kurven bei langsamer Fahrt.

Alles in allem also keine guten Voraussetzungen für eine schnelle und sichere Fahrt. Dennoch liefern diese Sektordaten einen wichtigen Beitrag zum Streckenmodell und werden deswegen unbedingt benötigt. Die Länge aller Geraden wird ausreichend zuverlässig ermittelt, auch die Länge und Radien der Kurvenstücke ist gut genug, um daraus eine maximal mögliche Fahrgeschwindigkeit abzuleiten. Lediglich die Reproduzierbarkeit bzw. der genaue phyikalische Ort der Sektorgrenzen ist verbesserungswürdig.

==== Was sind weiße/schwarze Sektoren und wie kann die Qualität der Sektordaten verbessert werden? ====

Um die Reproduzierbarkeit zu erhöhen, muss zusätzlich auf ein weiteres Verfahren zur Ermittlung von Sektorkenngrößen gesetzt werden. Um sprachlich hier nicht die beiden Konzepte zu vermischen, nennen wir die beiden Verfahren zur Sektorerkennung:
* Konzept "Band verlassen" oder "weißer Algorithmus bzw. weiße Sektordaten"
* Konzept "Charakteristische Stellen" oder "schwarzer Algorithmus bzw. schwarze Sektordaten"

Das Konzept "Band verlassen/weiße Sektoren" ist oben bereits beschrieben. Im folgenden wird der schwarze Algorithmus näher betrachtet. Übrigens, die Begriffe sind willkürlich gewählt und sollen rein zur Unterscheidung dienen.

Ziel des schwarzen Algorithmus ist es die Sektorgrenzen an einen festen Ort zu binden. Das Auto muss sich darauf verlassen können, dass der Bremspunkt korrekt sitzt. Kurvenradien zu erfassen oder besonders gute Abbildung des GyroZ-Verlaufs sind hier also nicht gefragt.
[[File:Sektorerkennung_(schwarz).png|right|360px|Sektorerkennung]]
Schaut man sich den GyroZ-Verlauf an einem Kurveneingang an, so fällt auf, dass dieser zunächst nahe 0 liegt und sich anschließend rampenförmig oder schon fast sprungförmig ändert. Kein Wunder, schließlich geht es ja von einer Geraden in eine Kurve über. Zur Erinnerung, die Carrera Schienenteile haben keinen weichen stetigen Übergang von Gerade in Kurve, sondern eine "unstetige Stelle". Aber selbst bei weichen Übergängen wäre ein Knick bzw. steiler Anstieg des GyroZ-Wertes vorhanden.
Wenn man sich den Punkt merkt, bei dem der GyroZ-Wert ein gedachtes Nullband verläßt (auch hier wieder ein virtuelles Band um die Nullinie vorstellen), dann sollte dieser Punkt in jeder Runde örtlich genau an der gleichen Stelle liegen. Am Ende einer (langen) Geraden fährt das Auto immer schnurgeradeaus. Um aber nicht Messrauschen oder kurzzeitige Schläge (z.B. durch die Stoßstellen der Schienen) fehlzuinterpretieren, wird verlangt, dass nach Abbiegen auch mindestens eine Kurve von 3° gefahren werden muss, sonst wird der Kurveneinlenkpunkt verworfen. Wurden aber die 3° "angesammelt", so gilt der Einlenkpunkt als Beginn eines neuen Sektors. Dieser Sektor endet erst wieder, wenn der GyroZ-Wert wieder ins Nullband zurückfällt UND es erneut verläßt (dabei natürlich wieder mehr als 3° überfährt).

Dadurch sind die schwarzen Sektoren nicht im geringsten mit den weißen Sektoren vergleichbar. Vereinfacht gesagt, beginnen und enden die schwarzen Sektoren immer an einem Übergang von Gerade in Kurve oder in S-Kurven. Dazwischen können aber beliebig viele andere Kurvenabschnitte liegen. Dies trifft auch für Kurven zu, deren Kurvenradius sich durch Aneinanderreihung von z.B. immer enger werdenden Schienenteilen ändert. Weiße Sektoren würden zu jeden einzelnen Schienenabschnitt einen Sektor liefern, der schwarze Sektor hingegen fasst diese alle zusammen.

Speichert man die weißen und schwarzen Sektordaten in zwei voneinander getrennten Listen, so erhält man für die Beispielstrecke folgende (idealisierte!) Tabellen:

{| class="wikitable" style="float:left; margin-right:1em"
|+ Weiße Sektoren
! SektorNr !! Sektorlänge !! Sektorwinkel !! Bandmitte !! WegpunktAbs
|-
| 0 || 0.00m || 0° || 0[raw] || 0.00m
|-
| 1 || 2.00m || 0° || 0[raw] || '''2.00m'''
|-
| 2 || 0.70m || -90° || -2200[raw]|| 2.70m
|-
| 3 || 0.30m || -60° || -3500[raw]|| '''3.00m'''
|-
| 4 || 0.25m || +60° || 3800[raw] || 3.25m
|-
| 5 || 1.00m || 0° || 0[raw] || '''4.25m'''
|-
| 6 || 0.90m || -90° || -1700[raw]|| 5.15m
|-
| 7 || 0.60m || 0° || 0[raw] || '''5.75m'''
|-
| 8 || 0.30m || -15° || -1600[raw]|| 6.05m
|-
| 9 || 2.10m || 0° || 0[raw] || '''8.15m'''
|-
| 10 || ... || || ||
|}

{| class="wikitable" style="float:left"
|+ Schwarze Sektoren
! SektorNr !! Sektoränge !! Sektorwinkel !! Kurvenlage!! WegpunktAbs !! Bezogen auf "weiß"
|-
| 0 || 0.00m || 0° || 0° || 0.00m || Initialsektor
|-
| 1 || 2.00m || 0° || 0° || '''2.00m''' || S1
|-
| 2 || 1.00m || -150° || -150° || '''3.00m''' || S2+S3
|-
| 3 || 1.25m || +60° || -90° || '''4.25m''' || S4+S5
|-
| 4 || 1.50m || -90° || -180° || '''5.75m''' || S6+S7
|-
| 5 || 2.40m || -15° || -195° || '''8.15m''' || S8+S9
|-
| 6 || ... || || || ||
|}
<div style="clear:both"></div>

Die weißen Sektoren dienen fortan ausschließlich als Streckenmodell. Die schwarzen Sektoren werden zur Synchronisierung/Positionsbestimmung verwendet. So kombinieren sich die Vorteile beider Sektorarten.

=== Positionsbestimmung/Synchronisierung ===
[[File:Signalflussdiagramm_Positionsbestimmung.png|180px|left|]]

Unsere erste Idee (die sich später allerdings als Sackgasse herausstellte), war es, zu Beginn eine Referenzrunde zu fahren. Die weißen Sektoren sollten das Streckenmodell (Referenzsektorliste) bilden. Später sollte dann nur noch ermittelt werden, wo wir uns momentan (bezogen auf die Referenzrunde) befinden. Da sich die Sektoren aber stark in Abhängigkeit der Fahrzeuggeschwindigkeit ändern, war das Streckenmodell schon veraltet, bevor es überhaupt genutzt werden konnte. Außerdem müsste zuverlässig erkannt werden können, wann die Referenzrunde zuende sein soll. Auch musste der gerade erfahrene Livesektor eindeutig einem Referenzrundensektor zuordenbar sein, wollte man die Synchronität nicht verlieren.
Das Vorgehen hätte dann so ausgesehen: Die Referenzfahrt liegt als komplette Liste vor und beinhaltet alle Sektoren der Runde. Der zuletzt gemeldete Sektor wird auf der Referenzsektorliste gesucht. Es wäre keine Liste mit aktuellen Sektordaten erforderlich gewesen. Nachteil: Würde auch nur eine Synchronisierung fehlschlagen, dann müsste die komplette Referenzfahrt erneut durchgeführt werden, da keine Infos über die letzten aufgelaufenen Sektoren vorlägen.

Als wesentlich geeigneter erwies sich das fortlaufende Aktualisieren nur einer Sektorliste nach dem FIFO-Prinzip. Einzige Bedingung: Die Runde darf nicht mehr Sektoren liefern, wie die Liste aufnehmen kann. Was natürlich die maximale Rundenlänge begrenzt, aber auch sicherstellt, dass immer die aktuellsten Daten vorliegen. Die Fahrt beginnt also mit einer Lernphase, deren einziger Zweck es ist, die Sektorliste zu füllen. Sobald dies erreicht ist, geht die Fahrt nahtlos in die eigentliche Ghostcarfahrt über und die Positionsbestimmung kann mit ihrer Arbeit beginnen. Ab jetzt wird schnell gefahren. (Derzeit umfasst die Liste 30 schwarze Sektoren, was auch für längere Strecken ausreicht).

'''''Ziel''''': Es muss ausgehend vom aktuellen Sektor, der Vergleichssektor gefunden werden, der zu dem Streckenabschnitt vor genau einer Runde passt. Kurzum: '''"Der Vorrundensektor muss gefunden werden"'''.
Die Positionsbestimmung wird immer dann ausgeführt, wenn ein neuer Sektor von der Sektorerkennung angeliefert wird.
Wenn die Positionsbestimmung zustandslos arbeitet, d.h. keine Infos aus vorangegangenen Synchronisationen für die aktuelle Rechnung benötigt, dann kann es auch nicht zu unheilbaren Fehlsynchronisationen kommen. Würde man auf dem Wissen aus den SyncRechnungen aus den vorherigen Sektoren aufbauen, so könnte man sich in eine Sackgasse manövrieren, aus der man (algorithmisch) nur schwer wieder heraus kommt.

Auf der Suche nach dem Vorrundensektor wird ''nicht'' einfach nur die gleiche Abfolge der ''letzten angefallenen'' Sektoren in der Sektorliste gesucht - da dies voraussetzen würde, dass die genaue Reihenfolge ohne Lücken und zusätzlichen Sektoren bereits so in der Liste steht. Wäre auch nur ein Sektor (z.B. wegen Überschwingern) hinzugekommen, dann käme der Algorithmus aus dem Tritt. Die Suche muss also robust gegen ausfallende bzw. zusätzliche Sektoren sein. Durch eine Ähnlichkeitssuche/Heuristik wird nicht die Reihenfolge der angefallenen Sektoren bewertet, sondern es wird versucht den Vorrundensektor über unabhängige Wahrscheinlichkeiten zu finden. Und das ist ganz ohne Sonderbehandlung zusätzlicher oder ausgefallener Sektoren möglich.

==== Heuristik: Wie läßt sich der Vorrundensektor zuverlässig aufspüren? ====

Getreu dem Motto "Wir können zwar nicht ausrechnen wo wir genau sind, dafür schätzen wir aber recht gut", setzen wir für die Positionisbestimmung ein heuristisches Verfahren ein. Eine statistische Auswertung der in Frage kommenden Vorrundensektoren soll uns dabei helfen. Alle nachfolgenden Berechnungen finden ausschließlich mit den eigens hierfür eingeführten schwarzen Sektoren statt.

Das Verschieben der Transparentpapierverläufe wird ersetzt durch numerisches Suchen von "ähnlichen" Sektoren.

Dabei wird in folgenden Schritten vorgegangen:
# Ähnlichkeitsmatrix aufstellen
# Häufigkeitsverteilung ermitteln
# gewichtete relative Wahrscheinlichkeiten errechnen

Am Ende steht der Sektor mit der höchsten Wahrscheinlichkeit als der gesuchte Vorrundensektor fest.

Doch der Reihe nach:

'''Was ist die Ähnlichkeitsmatrix?'''
[[File:Heuristik1.png|thumb|200px|right|Ähnlichkeitsmatrix und Häufigkeitsverteilung]]
Die Ähnlichkeitsmatrix beschreibt, ob sich sich zwei Sektoren ähnlich sind. "Ähnlich" bedeutet, dass sich die Sektordaten bis auf eine geringe Abweichung gleichen. ("Eine enge 50cm lange 90° Rechtskurve ist einer anderen 48cm langen engen 94° Rechtskurve ähnlich - aber nicht einer 130cm langen Geraden"). Aufgrund der reinen Zahlenvergleiche kann noch nicht sicher zwischen dem echten Vorrundensektor und einem an anderer Stelle liegenden ähnlichen Sektor unterschieden werden, was hier aber auch noch nicht der Fall sein muss. Hierfür kommt später dann die Gewichtung der so gefundenen Kandidaten ins Spiel.

Bei dieser Ähnlichkeitsbetrachtung wird jeder Sektor der Sektorenliste mit jedem anderen Sektor davor verglichen. Die Ergebnisse kann man sich als Matrix notiert vorstellen.

Die rechts gezeigte Ähnlichkeitsmatrix basiert auf nur sechs Sektoren pro Runde. Das wurde so gewählt, damit die Tabelle hier in der Darstellung noch handlich bleibt. Die Werte sind frei erfunden und dienen nur zur Verifikation des Algorithmus. Die tatsächlich gemessenen schwarzen Sektordaten sind deutlich reproduzierbarer. Die Zahlenreihe ist also ein Extrembeispiel für schlechte Sektordaten. Dennoch soll auch hiermit die Positionsbestimmung noch möglich sein.
(Die Zahlenwerte sind: 353, 208, 400, 479, 627, 125, 358, 207, 186, 211, 479, 619, 481, 207, 186, 214, 477, 607, 482, 207, 185, 210, 477, 585, 453, 206; ''das Ähnlichkeitskriterium hier sei ausschließlich der '''reine''' Zahlenwert''; Toleranz +-10).

''Lesebeispiel:'' Der aktuelle Sektor (hier: 25) wird vergleichen mit allen seinen Vorgängersektoren (also von 0..24). Daraus entsteht dann die unterste '''Zeile''' (Zeile 25). Für jeden Sektor, der dem Sektor 25 ähnlich ist, wird ein Kreuz gesetzt. Genauso wird für alle anderen Sektoren/Zeilen verfahren. Nach rechts wird ''nicht'' die Vergleichssektornummer aufgetragen, sondern die Anzahl der Zeilen, die die beiden Sektoren in der Liste voneinander trennen (also der "Abstand" bzw. das Delta der Sektornummern). Das Kreuz bei Zeile25/Spalte4 (=Z25S4) bedeutet somit: Sektor 25 ist dem Sektor ähnlich, der einen Abstand/Delta von 4 zu ihm hat - also Sektor 21 (25-4=21). => "Sektor 25 und Sektor 21 sind sich ähnlich". Diese Darstellung hat ihren Vorteil darin, dass sich die Rundenlänge (in Sektoren) mit einem Blick ablesen läßt. In vielen Zeilen ist in Spalte 6 ein Kreuz => eine komplette Runde besteht wahrscheinlich aus 6 Sektoren.
Übrigens, uns interessiert ja eigentlich der Vorrundensektor. Wenn wir aber wissen wie groß die (momentane) Rundenlänge ist, dann können wir daraus natürlich auch den Vorrundensektor errechnen.

'''Häufigkeitsverteilung'''

Die Häufigkeitsverteilung erlaubt eine Aussage darüber, welches die wahrscheinlichste Rundenlänge ist. Sie ist die Summe aller Kreuze in einer '''Spalte'''. Für Spalte 6 ergibt sich somit eine Häufigkeit von 13. D.h. 13 der 25 Sektoren sind denen ähnlich, die in der Liste 6 Sektoren davor stehen. Die Häufigkeitsverteilung fließt in die Berechnung der gewichteten relativen Wahrscheinlichkeit ein.

'''Was hat es mit der gewichteten relativen Wahrscheinlichkeit auf sich?'''

[[File:Heuristik2.png|thumb|200px|right|Häufigkeitsverteilung und gewichtete relative Wahrscheinlichkeit]]

Da die Ähnlichkeitsmatrix ''alle'' Sektoren liefert, die sich ähnlich sind, aber keine Bewertung/Gewichtung für den wahren Vorrundensektor einführen kann, muss diese Information über ein anderes Verfahren ermittelt werden.

Die für den Vorrundensektor relevante Zeile in der Ähnlichkeitsmatrix ist immer die letzte Zeile, also hier Zeile 25. Alle mit einem Kreuz versehenen Sektoren sind die Kandidaten, die für den Vorrundensektor in Frage kommen. Im Beispiel rechts sind das die Sektoren 21 (=25-4), 19 (=25-6), 13 (=25-12), 9 (=25-16), 7 (=25-18) und 1 (=25-24).
Doch welcher davon ist der richtige? Die Frage läßt sich mit der "gewichteten relativen Wahrscheinlichkeit" beantworten. Diese läßt sich so bestimmen:
Die Wahrscheinlichkeit, dass der jeweilige Kandidat dem gesuchte Vorrundensektor entspricht, verhält sich wie die Verteilung der Häufigkeit der Kandidaten (in der betrachteten Spalte) zur Gesamthäufigkeit.
Oder anders gesagt: Wenn häufig ein Kreuz in der Spalte für Rundenlänge=6 ermittelt wurde, dann ist die Wahrscheinlichkeit hoch, dass die wahre Rundenlänge tatsächlich 6 beträgt ("Mehrheitsentscheid"). Deswegen wird die Rundenlänge=6 auch bei der Positionsbestimmung für den aktuellen Sektor durch die relative gewichtete Wahrscheinlichkeit bevorzugt (=> "höherer Prozentwert").

Der Prozentwert errechnet sich aus dem Wert der Häufigkeitsverteilung * 100% dividiert durch die Sektorhäufigkeitssumme. Die Sektorhäufigkeitssumme ist die Summe aller in dieser Zeile beteiligten Häufigkeiten. Für Zeile 25 wäre dies: 4+13+6+1+2+1 = 27.
Für Zeile/Sektornr. 25 und Rundenlänge=4 (also für Vergleichssektornr. 21) erhält man 4*100/27 = 14%. Für eine Rundenlänge=6 ergibt sich ein Zahlenwert von 13*100/27 = 48%. Die restlichen Kandidaten haben eine relative gewichtete Wahrscheinlichkeit von 22%, 3%, 7%, 3%.

''Hinweis:'' Die Matrix (rechts) ist komplett mit Wahrscheinlichkeitswerten ausgefüllt. Für die Bestimmung des Vorrundensektors würde es auch ausreichen, wenn nur die unterste Zeile berechnet/dargestellt wäre.

'''''Der Kandidat mit der höchsten Wahrscheinlichkeit soll als Vorrundensektor anerkannt werden.''''' In diesem Fall ist dies der Sektor 19 mit Rundenlänge/Delta=6. Ein Blick in die Liste der Zahlenwerte (im Text oben) ergibt: Sektor25 hat einen Zahlenwert von 206, Sektor19 hat einen Zahlenwert von 207 => passt.

Für manche Zeilen lassen sich überhaupt keine Kandidaten finden, d.h. es kann kein Vorrundensektor bestimmt werden. => Infolge darf das Auto nur mit verringerter Geschwindigkeit weiterfahren, bis die Position auf dem Streckenmodell erneut feststeht (=wieder ein Vorrundensektor ermittelt werden kann). Die nächste Gelegenheit hierzu bietet sich dann, wenn der nächste schwarze Sektor gemeldet wird.

Aber selbst wenn ein Kandidat mit einem hohen Prozentsatz (oder gar mit 100%) versehen ist, heißt dies nicht zwangsläufig, dass dies auch der wahre Vorrundensektor ist. Tatsächlich könnte es auch sein, dass dieser durch besondere Ereignisse (z.B. Räder drehen für längere Zeit durch) komplett "versteckt" ist und nicht mehr dem wahren Vorrundensektor ähnlich ist (evtl. aber jetzt zufällig einem anderen).

Aus den ermittelten Kandidaten deutet die relative gewichtete Wahrscheinlichkeit denjenigen heraus, der es mit der höchsten Wahrscheinlichkeit auch ist. (Nebenbei bemerkt: Bisher hat sich das Gcp praktisch noch nicht einmal verbremst und ist deswegen aus der Kurve geflogen, hat aber öfters keinen Kandidaten finden können und musste deswegen bis zum nächsten Syncpunkt langsam fahren).

Da die Rundenlänge hier ja nur 6 Sektoren beträgt, die Liste aber 26 Sektoren aufnehmen kann, müssten doch eigentlich mehrere Runden in der Liste auftauchen. Wieso synchronisiert sich der Algorithmus nicht versehentlich auf z.B. -12 Sektoren auf? Das könnte theoretisch durchaus passieren. In der Ähnlichkeitsmatrix sieht man auch in Spalte Delta=12, Delta=18 (schon weniger) und Delta=24 (nur sehr theoretisch) ebenfalls Ähnlichkeitshäufungen. Das Problem löst sich quasi von selbst, da die oberen Zeilen weniger Kreuze beitragen können (und wenn überhaupt, dann liegen diese wegen der Dreiecksform in den linken Spalten) und erfahren deswegen auch eine geringere Gewichtung.

Was passiert eigentlich in Zeile 9 oder Zeile 12? Hier vertut sich der Algorithmus komplett und wählt einen falschen Kandidaten. Würde das mit echten Messwerten passieren, dann könnte das Fahrzeug letztendlich von der Strecke fliegen.

Wieso beträgt in Zeile 10 und 11 die angebliche Rundenlänge = 7 Sektoren? Das liegt daran, dass in der Vorrunde (von Sektor 10 und 11), sich ein Sektor in zwei Sektoren aufgeteilt hat (z.B. durch Drift). Die Positionsbestimmung liefert also (auch) in diesem Fall einen korrekten Wert. Die Rundenlänge muss nicht für alle Ewigkeit konstant sein, sondern kann sich dynamisch zur Laufzeit ändern.

''' Was heißt eigentlich: Zwei Sektoren sind sich ähnlich?'''

Als Kriterien zur Ähnlichkeitsbestimmung dienen Sektorlänge, Sektorwinkel und Sektorlage. Die Begriffe Sektorlänge und Sektorwinkel sind aus obiger Beschreibung schon bekannt. Die Sektorlage ist die Ausrichtung des Sektors in der Ebene (z.B. der Sektor liegt im 270°-Winkel zur Start-Ziel-Geraden). Erst wenn alle Parameter mit ihrem Wert innerhalb eines erlaubten Toleranzbereiches sind, gelten zwei Sektoren als "ähnlich".
Für die Sektorlänge haben sich 10 Wheelticks bewährt (das sind 10*17.5mm, also 17.5cm), der Sektorwinkel muss auf 5° identisch sein und die Lage darf um 60° abweichen. Das liegt im Langzeitdrift des Gyros begründet. Nach einer Drehung (z.B. nach einer Runde) liefert der Gyro nicht genau 360°, sondern weicht um bis zu 30° ab. Für Strecken die mehr als 360° Rundenwinkel haben (z.B. zwei ineinander verschachelte Schleifen), muss die Lage folglich n*30° tolerieren (bei uns momentan auf 60° parametriert).

=== Fahrprofil: Jetzt steht der (schwarze) Vorrundensektor fest, was nun? ===
[[File:Signalflussdiagramm_Fahrprofil.png|180px|left|]]

Der Vorrundensektor in der schwarzen Sektorliste liefert uns den Punkt, auf dem wir uns vor einer Runde befanden. Und da sich die Streckenführung definitionsgemäß nach genau einer Runde wiederholt, darf man ruhigen Gewissens davon ausgehen, dass der Vorrundensektor+1 derjenige Sektor ist, der als nächstes erreicht wird.

Doch die schwarzen Sektoren liefern nicht die Infos, die zur Berechnung von Bremspunkt und maximaler Kurvengeschwindigkeit notwendig sind. Ein Wechsel zur weißen Sektorliste ist erforderlich. Das Bindeglied zwischen den Listen sind die absoluten Wegpunkte. Wegpunkte sind die aufaddierten Wheelticks (Reflexkoppler-Pulse) und werden in jeder Fahrt kontinuierlich hochgezählt - sie wiederholen sich nie (vergleichbar mit dem Gesamtkilometerzähler im echten Auto). Da bekannt ist, an welchem Wegpunkt der schwarze Vorrundensektor lag, kann in der Liste der weißen Sektoren derjenige Sektor gesucht werden, in dessen Bereich ebenfalls dieser Wegpunkt fällt (Muss ja nicht zwangsläufig auf eine weiße Sektorgrenze fallen). Jetzt ist der Abstand zur nächsten (weißen) Sektorgrenze bekannt und auch der charakteristische GyroZ-Wert (Bandmitte) des nächsten Sektors liegt vor.

'''Woher weiss das Fahrzeug mit welcher Geschwindigkeit ein bestimmter Kurvenradius gefahren werden kann?'''

[[File:Kennlinie_GyroZ2Rpm.png|200px|right|Kennlinie GyroZ->RPM]]

Zunächst einmal hängt die maximale Kurvengeschwindigkeit eines Fahrzeugs von seiner Bodenhaftung (u.a. Magnet im Unterboden, Fahrbahnbelag, Gewichtsverteilung, Reifenart usw.) ab und muss für jedes Fahrzeug einmalig ermittelt werden. Bestimmt man diese Geschwindigkeit exemplarisch für einen oder zwei bestimmte Kurvenradien, so kann man dies auf andere Kurvenradien inter-/extrapolieren. Aus der Physik wissen wir, dass sich die maximale Kurvengeschwindigkeit bei doppeltem Kurvenradius um Faktor Wurzel2 erhöhen darf. (Zentripetalkraft Fz = m*v²/r). Diese Aussage wird durch praktische Beobachtungen gestärkt. Es läßt sich so ein Zusammenhang aufstellen, der in Abhängigkeit des GyroZ-Wertes (Betrag) eine maximal mögliche Drehzahl (=Geschwindigkeit) aufzeigt. Verpackt in einer (Lookup)Tabelle ergibt sich für unser Fahrzeug die rechts abgebilde Kennlinie. Der hyperbelförmige Verlauf wird durch einen unteren Wert begrenzt (hier z.B. 1400RPM). Dieser Wert steht für die Drehzahl, die auch am langsamsten Streckenabschnitt noch problemlos gefahren werden kann. Für Geraden (GyroZ=0) wurde eine Drehzahl von 8000RPM festgelegt. Diese wird mit unserem Fahrzeug auch bei sehr langen Geraden noch nicht erreicht. Übrigens, wenn von "Drehzahl" die Rede ist, ist damit immer die Drehzahl der Hinterachse gemeint. Die Motordrehzahl ist durch das Getriebe nochmals um den Faktor 3 höher.

'''Wann muss gebremst werden?'''

Aus der Momentangeschwindigkeit, und der im nächsten Sektor erlaubten Maximalgeschwindigkeit (ermittelt aus der Kennlinie) läßt sich der Bremsweg berechnen. Passt der Bremsweg gerade noch in den aktuellen Sektor hinein, dann wird's Zeit zu bremsen.
[[File:Bremsvorgang.png|200px|right|Bremsvorgang]]
Das Bremsen wird dadurch erreicht, dass die Solldrehzahl langsam verringert wird (Bremsrampe). Eine sprungförmige Drehzahländerung würde zwar maximal stark verzögern, könnte aber in Kurven auch zu Instabilitäten des Fahrzeugs führen. Wenn sich z.B. eine schnelle Kurve "plötzlich" zuzieht, dann könnte das Fahrzeug beim abrupten Bremsen ausbrechen. Umgekehrt wird auch nicht sprungförmig beschleunigt, um keine durchdrehenden Räder zu provozieren (kein Magnet im Fahrzeugunterboden verbaut => wenig Bodenhaftung => Vollgas => durchdrehende Räder). Legt man die maximal (gewünschte) Verzögerung, als auch die maximal (gewünschte) Beschleunigung als Einstellparameter aus, so lässt sich der Algorithmus an Fahrzeug und Strecke anpassen. Es wäre auch denkbar, dass diese Parameter in einer Kalibrierfahrt automatisch von der Software ermittelt werden.

'''Muss überhaupt gebremst werden?'''

Liefert die Bremswegberechnung quasi einen negativen Bremsweg, d.h. die Drehzahl muss an der Sektorgrenze nicht verringert werden, dann muss geprüft werden, ob nicht sogar beschleunigt werden darf.
Beschleunigt werden darf immer dann, wenn die Maximalgeschwindigkeit für den ''aktuellen'' Sektor noch nicht erreicht ist. ''Vor'' der Sektorgrenze darf noch nicht beschleunigt werden (also nicht wie im echten Auto bereits im Kurvenscheitel), da ja die Carrera Schienenteile einen konstanten Radius haben und somit in der ganzen Kurven nur ''eine'' (optimale) Geschwindigkeit erlauben. Ein früheres Beschleunigen würde zu übermäßigem Drift führen und letztendlich zu langsamerer Rundenzeit. Nebenbei bemerkt: Für frei gefräste Holzbahnen würde eine zulaufende Kurve durch die Sektorerkennung schon in mehrere Abschnitte aufgeteilt werden und diese Besonderheit würde sich dort nicht ergeben.

=== Drehzahlregler ===
[[File:Signalflussdiagramm_Drehzahlregler.png|180px|left|]]

Die von der Sollgeschwindigkeitsberechnung ermittelte Solldrehzahl ("SollRPM") wird an den Drehzahlregler übergeben, der daraus ermittelt, mit welchen PWM-Tastverhältnissen die Motortreiber-Mosfets angesteuert werden müssen. Es gibt einen Kanal zur Ansteuerung des "Fahr-Mosfets", der die Schienenspannung auf den Motor schaltet und einen Kanal für den "Brems-Mosfet" zum aktiven Bremsen, der den Motor kurzschließt. Beide dürfen natürlich nicht gleichzeitig angesteuert werden, da es sonst zu einem harten Kurzschluß kommt.

Der Regler ist als PI-Regler ausgelegt. Die Reglerparameter wurden experimentell so ermittelt, dass eine möglichst schnelle Annäherung an die Führungsgröße (SollRpm) gegeben ist, ohne dass der Regler (stark) überschwingt.

Die PWM-Kanäle werden mit 25kHz betrieben und lösen das Tastverhältnis in 0.1%-Schritten auf.

<div style="clear:both"></div>

== Elektronik ==

Als Spenderfahrzeug für das Gcp musste ein ausrangiertes Carreraauto herhalten, dessen Elektronik durch eine eigene Platine ersetzt wurde. Neben den Sensoreingängen und den Motortreibern erwies sich auf dem Prototypen auch eine Kommunikationsschnittstelle zum PC für Logging/Debug-Aufgaben als zwingend notwendig.

[[File:Schaltplan_Gcp.png|200px|right|thumb|Schaltplan Gcp v2.10]]
[[File:Layout-top_Gcp.png|200px|right|thumb|Layout Oberseite ]]
[[File:Layout-bottom_Gcp.png|200px|right|thumb|Layout Unterseite]]

{| width="70%" cellspacing="1" cellpadding="3" border="2"
|-
| bgcolor="#f7f7f7" |
'''Technische Daten:'''
* Sensoren/Aktoren:
** 3-Achsen-Gyrosensor: L3G4200D von ST
** Reflexkopplerlichtschranke zur Drehzahlerfassung: SFH9202
** Motortreiber + Mosfets: AUIRS4427S + IRF7343 (zweikanalig zum Beschleunigungen und aktiven Bremsen)
** Einlesemöglichkeit der Schienendaten (Carrera Digital); Spannungsmessung
** IR-Sendediode im Fahrzeugboden zum Schalten der Carrera Weichen
** Ansteuerung der Fahrzeug LEDs (Fahrlicht, Bremslicht)
** Magnet-Winkelencoder am Leitkiel (AS5045; Optional, zur Messung der Leitkielstellung, Driftwinkel usw.)
** (Beschleunigungssensor nicht (mehr) verbaut)
* Kommunikation:
** RS232-Kommunikationsinterface über Aufsteckplatine (BT-Modul von Free2Move im transparenten RS232-Modus)
** Piezo-Piepser
* Prozessor:
** Freescale HCS12C96 (50MHz); 3.3V; 96k Flash (10k benutzt); 4k RAM (3k benutzt)
 
|}

Der Gyrosensor liefert einen '''Drehratenwert''' (skaliert in 70 MilliDegrees per Second; mdps) und wird zyklisch jede 1ms ausgelesen.

Zur '''Drehzahlmessung''' (und '''Entfernungsmessung''') wurde auf der hinteren Antriebsachse eine Scheibe angebracht, die pro Radumdrehung 8 Flankenwechsel liefert. Da wir momentan nur die High-Low-Flanken auswerten erhalten wir bei einem Radumfang von 70mm eine Auflösung von 17.5mm pro Reflexkoppler-Impuls. Der Impuls wird nicht nur gezählt, sondern der genaue Zeitpunkt wird zusätzlich per InputCapture-Einheit erfasst, um eine deutlich höhere zeitliche Auflösung zu erhalten und somit die Raddrehzahl auch bei "niedrigen" Drehzahlen sauber erfassen zu können. Im relevanten Drehzahlbereich von ca. 1000RPM..8000RPM kommt im Schnitt etwa alle 1..10ms ein Wheeltick (=17.5mm).

Die beiden Beschleunigungs- und Bremsmosfets werden mit einem Mosfet-Treiber angesteuert, da diese weniger Platz auf der sowieso knappen Platinenfläche einnimmt und auch die Dimensionierung der sonst notwendigen diskreten Mosfet-Beschaltung vereinfacht.

[[File:Uebersichtsplan_HW.png|450px|left|thumb|Übersichtsplan HW]]
Der verwendete HCS12-Prozessor von Freescale wurde gewählt, weil dieser aus anderen Projekten bereits vertraut war und die technischen Daten (Taktfrequenz, Speicher) dem Einsatz nicht im Wege standen, bzw. alles so ausgelegt wurde, dass die Ressourcen passen.

Versuche mit '''3-Achsen-Beschleunigungssensoren''' brachten keine befriedigenden Ergebnisse, weshalb diese (auch aus Platzgründen) nicht verbaut wurden. Das Nutzsignal war in der gleichen Größenordnung wie das Rauschen, woraus sich keine sinnvoll verwertbaren Daten ableiten ließen. Ursache dafür waren vermutlich die starken Motor- und Fahrbahnvibrationen, die sich trotz mechanischer Entkopplung (Moosgummi) nicht ausreichend verbesserten.

Der '''Leitkielwinkelsensor''' wurde als Vorhalt eingeplant, um den fahrdynamischen Grenzbereich (wenn das Fahrzeug langsam in den Drift übergeht) besser ausmessen zu können. Der Leitkiel ist eine Führungsschiene im Unterboden des Fahrzeugs, die im Schlitz in der Fahrbahn entlangläuft und zur Spurführung dient.
Hierzu wird die Leitkielstellung relativ zum Fahrzeug gemessen. Bei Kurveneinfahrten dreht sich der Leitkiel relativ zum Fahrzeug ein Stück zur Seite. Übersteigt dieser Winkel einen bestimmten Wert, so kann man daran ein Driften des Fahrzeugs ablesen. Durch Montage eines kleinen Magneten auf dem Leitkiel läßt sich dessen Winkel bzw. Verdrehung relativ zum feststehenden MagnetWinkelencoder messen.
Der magnetische Winkelauflösung beträgt 12Bit, was ca. 0.1° entspricht - also weit genauer als hier nötig wäre. Alle 4ms wird ein neuer Messwert geliefert.
Derzeit messen wir den Leitkielwinkel zwar, verwerten die Daten aber nicht. Grund: Da die Montage relativ aufwendig ist (modifizierter Leitkiel; Befestigungsmöglichkeiten), wollten wir nur dann auf die Daten zurückgreifen, falls eine ausreichend schnelle Fahrt nicht ohne diesen möglich wäre.

Das Einlesen der Carrera Digitaldaten auf den Schienen ist dazu gedacht, um das Fahrzeug vom Benutzer parametrieren und manuell fahren zu können. Denkbar wäre es z.B. die Fahrgeschwindigkeit künstlich einzuschränken oder den Fahrbeginn vom Benutzer per Handregler starten zu können.
Voraussetzung dafür ist ein schnelles und ungepuffertes Einlesen der Schienenspannung. Die Schiene führt bei Digitalbahnen auf der einen Spur Gnd und auf der Anderen einen Pegel von 12-18V je nach Trafo. Zur Kommunikation von der Carrera-Steuereinheit zum Fahrzeug ist der Gleichspannung ein PWM-Signal überlagert. Eine Datenübertragung vom Fahrzeug zur Steuereinheit ist nicht vorgesehen.
Das ungepufferte Einlesen der Schienenspannung steht in entgegengesetzter Anforderung zu einer stabilen Spannungsversorgung für die Elektronik. Durch Lücken in der Schiene ("Weichen") kommt es zu Aussetzern von ein paar wenigen Zentimetern bzw. wenigen hundert Millisekunden, die von einem Stützelko überbrückt werden müssen. Die überlagerten Kommunikationssignale sind deshalb (per Diode) von der internen Versorgung entkoppelt.

Grundsätzlich unterstützt das GCP auch Analogbahnen mit einer konstanten Spannungsversorgung (=> "Handregler per Klebeband auf Vollgas fixieren")

Die '''IR-Sendediode''' im Fahrzeugboden erlaubt bewusst eingeleitete Spurwechsel, um z.B. jederzeit auf der Ideallinie fahren zu können. Um die anderen Fahrzeug nicht abzuschießen, würde das aber praktisch auch mehr Rundumsicht benötigen (=> "Abstandssensoren"). Automatische Spurwechsel sind derzeit aber noch nicht implementiert.

Um den Reflexkoppler einzusparen, und so den Nachbau zu erleichtern, bzw. zu verbilligen, haben wir auch die Drehzahl ohne Reflexkoppler getestet ("Drehzahlmessung per Gegen-EMK"). Dabei wird ausgenutzt, dass die im Motor induzierte Gegenspannung proportional zu seiner Drehzahl ansteigt. Misst man diese "elektromotorische Kraft" zu einem Zeitpunkt in der der Motor nicht bestromt wird ("PWM-Aus"-Phase), so kann man eine Aussage über seine Drehzahl treffen. Praktisch funktioniert dies auch prinzipiell, allerdings war die Messung nicht so genau wie die Drehzahlmessung per Reflexkoppler, was dann den Regler (bzw. unsere Reglerparameter) überforderte. Das Fahrzeug fuhr deutlich "unrunder". Das Motorgeräusch war schrecklich. Deshalb haben wir diese Option bisher auch noch nicht weiter vertieft, obwohl da noch Verbesserungsotential stecken dürfte.

<div style="clear:both"></div>

== Software ==

Neben den obligatorischen Komponenten wie Scheduler und Lowlevel-Treibern (InputCapture, Pwm, Adc, Spi) besteht der Kern der Gcp-Software aus den beiden Komponenten Kommunikationsmodul (ApplComm) und allem, was mit der Bestimmung Fahrzeugposition und Ansteuerung des Motors zusammenhängt (ApplLap).

=== ApplLap: Sektorerkennung, Positionsbestimmung und SollDrehzahlberechnung ===

[[File:Sourcecode.png|61px|left|ApplLap.c|link=http://www.mikrocontroller.net/attachment/172165/ApplLap.c]]

Die oben beschriebenen Konzepte und Ideen sind im Modul ApplLap ([http://www.mikrocontroller.net/attachment/172165/ApplLap.c Download]) implementiert. Der zentrale 1ms-Task, in dem alle zyklisch anfallenden Arbeiten ausgeführt werden, verwaltet die einzelnen Teilkomponenten, wie Sektorerkennung weiß, Sektorerkennung schwarz und SollDrehzahlberechnung.
Die Teilkomponente Positionsbestimmung ist weniger zeitkritisch, aber relativ rechenzeitintensiv, weshalb diese nicht wiederkehrend alle 1ms gerechnet wird, sondern nur dann, wenn ein neuer potentieller Syncpunkt anfällt (also ein neuer schwarzer Sektor geliefert wird). Die Ausführung findet im IdleTask statt, der immer dann (weiter)gerechnet wird, wenn der 1ms-Task seine Arbeit erledigt hat. Die Positionsbestimmung wird somit ständig von den zyklischen 1ms-Aufgaben unterbrochen. Es ist mit dem aktuellen Stand der Software so, dass der 1ms-Task maximal 820µs Laufzeit verbraucht und für den Idletask pro 1ms nur (minimal) 180µs Rechenzeit übrig bleiben. Letztendlich liefert die Positionsbestimmung dann aber nach spätestens 30ms einen neuen Syncpunkt. (Der zwischenzeitlich verfahrene Weg wird natürlich berücksichtigt).

=== ApplComm: Kommunikation zum PC ===

[[File:Sourcecode.png|61px|left|ApplComm.c|link=http://www.mikrocontroller.net/attachment/172166/ApplComm.c]]

Das Kommunikationsmodul ([http://www.mikrocontroller.net/attachment/172166/ApplComm.c Download]) implementiert ein kleines Protokoll zur Datenübertragung zum PC. Hierüber werden in verschiedenen Modi (die vom PC vorgegeben werden) folgende Daten vom Fahrzeug an den PC gesendet:
* '''LiveMeasure-Daten''': interne Variablen zur (grafischen) Echtzeitanalyse, wie z.B. MomentanDrehzahl, SollDrehzahl, aktueller GyroZ-Wert, Debugvariablen usw.; bis zu 6 Parameter werden (typ.) alle 50ms übertragen.
* '''Fastlog''': Echtzeitübertragung aller physikalischen Eingangsgrößen(!)
* '''weiße und schwarze Sektordaten''': Länge, Wegpunkt, Winkel, Lage, Bandmitte zur späteren automatischen oder händischen Auswertung.
* SyncTelegramme: Wegpunkt der Synchronisierung und um wieviele Wheelticks ("cm") die errechnete Position korrigiert werden musste
* Diagnosedaten, wie z.B. Prozessorauslastung im 1ms-Task/Idle-Task, um Ressourcenprobleme erkennen zu können.

== PC-Software zur Auswertung und Simulation ==

Die empfangenen '''LiveMeasure'''-Daten werden von einer dafür entwickelten PC-Software in Echtzeit in einen Graphen eingetragen und helfen somit bei der visuellen Bewertung der Fahrzeugsituation. Hilfreich ist dies z.B. beim Aufspüren von Fahrzeugdrifts am Kurvenein- oder ausgang (GyroZ-Sprung/Schwinger im Graphen) oder bei der Bewertung der Reglerparameter ("Istdrehzahl schwingt über"). Da hierbei nicht alle Messwerte übertragen werden können, reicht diese Analysemethode nur für erste grobe Einschätzungen.

Daneben gibt es aber viele Situationen, die schwieriger zu bewerten sind. Zum einen, weil nicht alle, zur Analyse nötigen Daten, vorliegen (50ms Aktualisierungsrate reicht oft nicht aus), zum anderen, weil die 6 Livemeasure-Kanäle nicht ausreichen.

Die Frage "Wieso wurde die Sektorgrenze nicht gesehen" läßt sich nicht nur durch Betrachten des GyroZ-Verlaufes beantworten, sondern es ist notwendig den Algorithmus live zu beobachten. Da sich das Fahrzeug aber bewegt und sich damit eine Onboard-Debugmöglichkeit ausschließt, mussten die Daten zur späteren Auswertung aufgezeichnet werden. Hierzu nimmt der PC die in Echtzeit / live gesendeten physikalischen Messgrößen entgegen (Betriebsart "'''Fastlog'''" und liegt diese in einem Logfile ab. Dadurch können auch sehr lange Messfahrten problemlos aufgezeichnet werden.
Am Ende werden die phyikalischen Eingangsgrößen am PC genauso nachgerechnet, wie diese auch im Fahrzeug berechnet wurden. So ist es möglich zu beliebigen Zeitpunkten und an beliebigen Stellen das Verhalten des Algorithmus zu betrachten/debuggen und die grafische Ausgabe zu analysieren.
Die PC-Software enthält hierzu eine Komponente (Targetcode.cs), in dem der (relevante) Microcontrollercode fast 1:1 identisch nachgerechnet wird. Die Dateien lassen sich relativ einfach per Diff-Tool auf gleichem Stand halten.

Um algorithmische Probleme zu lösen, die keinen Echtzeitbezug benötigen, reichen die Daten der Sektortelegramme aus.
Für die heuristische Positionsbestimmung z.B. ist eine Simulation umgesetzt, die als Eingangsdaten, rein die gelieferten Sektordaten benötigt. In der Ausgabe der Simulation lassen sich somit einfach die Ähnlichkeitsmatrix, Häufigkeitsverteilung oder gewichtete relative Wahrscheinlichkeit realer Fahrzeugsituationen analysieren.

[[File:Vorschaubild-Video-(Simulation-Sektorerkennung).png|200px|right|Simulation Sektorerkennung|link=http://youtu.be/bM2tu5I-Dqs?hd=1]]
Auch das Bestimmen der Parameter für die Sektorerkennung (weißer Algorithmus) ließ sich sehr anschaulich über eine PC-Simulation lösen. Hier kann in Echtzeit grafisch beobachtet werden, welchen Einfluss das Verstellen der Parameter auf die Wahl der Sektorgrenzen hat (siehe [http://youtu.be/bM2tu5I-Dqs?hd=1 Video]). So ist schnell überprüfbar, ob die Sektordaten sinnvoll die tatsächliche Kurvenform (GyroZ-Verlauf) wiedergeben können.

'''Fazit''': Ohne die umfangreichen Simulationsmöglichkeit wäre es unmöglich gewesen auch nur ansatzweise ein autonom fahrendes Fahrzeug zu bauen. Der Einsatz des Prozessordebuggers konnte auf die Fälle beschränkt werden, an denen (einfache) elektrische/physikalische Probleme auftaten (z.B. Probleme beim Einlesen der Reflexkoppler-Daten aufgrund von Prellen, bzw. der elektrische Signalform und bei Implementationsfehlern im Kommunikationsprotokoll...). Die restlichen, schwierigeren algorithmischen Implementationsprobleme ließen sich komfortabel in der Simulation austesten.

== Probleme bei Planung und Durchführung ==

Schneller als erwartet und ohne ernste Probleme ging die Entwicklung der Hardware inkl. Grundsoftware von statten. Schon nach wenigen Wochen(enden) hatten wir ein erstes fahrfähiges Muster in der Hand. Da dieses bereits dank Drehzahlerfassung mit konstanter Drehzahl fahren konnte und nicht mit konster PWM fahren musste (das führt in Kurven dazu, dass die Geschwindigkeit aufgrund erhöhter Reibung minimal einbricht), war das GCP bereits geringfügig schneller als das original Carrera Ghostcar. Eigentlich war unser erstes Projektziel damit schon erreicht.

Danach ging es an die Erfassung des Streckenmodells ("weißer Algorithmus"). Wir konnten ohne PC-Simulation und ohne Livedatenerfassung aus dem Fahrzeug nicht zu brauchbaren Parametern für den weißen Algorithmus gelangen. Also musste eine umfangreiche Log-/Debug-Infrastruktur aufgebaut werden. Die Ideen zur Verbesserung der weißen Sektordaten bzw. "Erfindung" des schwarzen Algorithmus ließen etwas auf sich warten, waren aber einige Wochen und (Matlab)Simulationen später, umsetzungsreif und implementierbar.
Das größte und am meisten unterschätzte Problem war jedoch die eigentliche Positionsbestimmung. Nachdem bereits gute und reproduzierbare Sektordaten vorlagen, waren wir zunächst guter Dinge, dass dies nur noch ein kleiner Schritt sein müsste.
Wir waren bis dahin davon ausgegangen, dass wir mit einer Referenzfahrt zur Aufzeichnung der Sektordaten beginnen könnten, die dann in die Ghostcarfahrt übergehen würde. Wir konnten keine Kriterien finden, die sauber bei jedem denkbaren Streckenverlauf ein Rundenende erkennen konnte. (Theoretisch kann man dies wohl beweisen/erkennen, wenn man bereits zwei(!) vollständige Runden zurückgelegt hat - praktisch ist uns das algorithmisch aber nicht zuverlässig gelungen).

[[File:Vorschaubild-Video-(Fahrt).png|200px|right|Ghostcar-Fahrt|link=http://youtu.be/k1GCKp2Ms3Q]]
Letztendlich vergingen ungefähr 8 Monate bis das Konzept der Positionsbestimmung in der jetztigen Form feststand. Damit waren alle Voraussetzungen für eine autonome Fahrt geschaffen. Es war ein spannender Augenblick, als das Auto zum ersten Mal auf Geraden beschleunigte und vor Kurven rechtzeitig bremste. (Siehe [http://youtu.be/k1GCKp2Ms3Q Video]) Eigentlich wollten wir vorher noch das Fahrzeug gegen Einschläge polstern, was dann aber doch irgendwie vergessen wurde...

Auch wenn zum aktuellen Projektstand das Gcp noch keine Konkurrenz für einen trainierten Fahrer ist, so fährt es Anfängern doch davon. Es ist also noch Potential nach oben vorhanden, vor allem, wenn man Drifts zur Verbesserung der Rundenzeit zuläßt. Sofern man überhaupt davon ausgeht, dass damit die Rundenzeit tatsächlich schneller wird - was noch zu beweisen wäre...

== Verbesserungsideen ==

*'''Alles was die Rundenzeit verbessert'''
** Auswertung des Leitkielwinkels zur Erkennung von fahrdynamischen Grenzbereichen; "Kontrolliertes driften"
** Durch Überschwinger am Kurvenende bei höherer Geschwindigkeit werden zusätzliche schwarze Sektoren erzeugt, die bei langsamerer Fahrt nicht auftreten und deswegen zu Syncproblemen führen. Diese zusätzlichen Sektoren könnten ausgeblendet/unterdrückt werden (Modifikation Schwarzer Algorithmus) und somit eine höhere Grundgeschwindigkeit gefahren werden. (Derzeit fahren wir noch nicht an der physikalischen Haftgrenze, sondern an der "Reproduzierbarkeitsgrenze" der schwarzen Sektoren).

* '''Alles was die Fahrt besser macht'''
** Beschleunigen nicht nach Streckenmodell, sondern nur nach aktuellem GyroZ. Dadurch wird der Beschleunigungspunkt nicht "verpasst" und auch nicht zu früh begonnen zu beschleunigen.
** Dynamische Bandhöhe: Eine höhere Auflösung der gewählten Bandhöhe bei kleinen GyroZ-Werten würde zu weniger gemeldeten weißen Sektoren führen und damit weniger Speicherplatz bzw. Listenplätze belegen. Würden die angelegten Bänder um den GyroZ-Wert nur im Bereich um GyroZ -1000..+1000 hoch aufgelöst werden, weil genau in diesem Bereich hohe Geschwindigkeiten gefahren werden (können), so müsste man die Momentangeschwindigkeit nicht vom (betragsmäßig) größten GyroZ-Wert in diesem (hohen) Band abhängig machen => ebenfalls schnellere Fahrt möglich.
** Die Bremspunktbestimmung schaut momentan zwei Sektoren in die Zukunft. Würden zwei sehr kurze, aber schnelle Sektoren anstehen, aber ein dritter sehr enger Sektor folgen, könnte dieser übersehen werden und das Bremsen zu spät eingeleitet werden. (Unklar, ob eine solche Strecke mit Carreraschienen praktisch überhaupt gebaut werden kann).
** "GapSektoren": Als weiteres Kriterium für die Positionsbestimmung könnte die Lage der "Schienenlücken" (Unterbrechungen der Stromleiter durch Weichen, Kreuzungen) dienen. Erkennung durch Schienenspannungsmessung; Vorteil: ortsfest; Nachteil: Nicht auf allen Bahnen vorhanden; Ausgiebige Tests zeigten sehr gute Eignung

* '''Alles was das Fahren interessanter machen könnte'''
** Abstandssensoren, um Spurwechsel überhaupt erst zur ermöglichen (kein Abschießen von nebeneinander fahrenden Autos) und um dicht vor oder hinter einem anderen Fahrzeug fahren zu können.
** Einstellbare Geschwindigkeit des Ghostcars, um sich auf verschieden starke Gegner abstimmen zu können
** Tuningparameter vom Benutzer einstellbar machen. Dadurch könnte dieser sein Fahrzeug auf seine Strecke abstimmen. Dies könnten z.B. folgende Parameter sein:
*** '''maximale Beschleunigung''' (bessere Reifen, besserer Grip => höhere Beschleunigung möglich). Eine zu hoch eingestellte Beschleunigung würde zu durchdrehenden Rädern führen und somit Rundenzeit kosten.
*** Variation des ermittelten Bremspunkts: Wie knapp soll wirklich gebremst werden (Sicherheitsreserve vs. Risiko)
*** '''Kennlinie'''; Abhängigkeit der Geschwindigkeit vom Kurvenradius (hohes Optimierungspotential; stark Strecken- und Fahrzeugabhängig)
** Ausnutzung der Weichen, um Wegstrecke zu sparen
** und noch viele weitere Ideen...

== Sonstiges ==

Aufgrund des begrenzten Umfangs dieses Artikels, müssen leider viele Punkte offen bleiben oder werden nur in einem kurzen Nebensatz angerissen. Sollten noch Fragen auftauchen, bitte melden.

GCP ist ein Freizeitprojekt von and_ref und galoscha.
Eine kommerzielle Verwertung ist nicht gestattet. Bei entsprechendem Interesse bitte anfragen. :-)

'''Kontakt''': André; and_ref (at) canathome.de

[[Kategorie:Wettbewerb]]

GhostCarProjekt

2013-03-08T19:35:01Z

And ref: Tippfehler korrigiert

''von and_ref''

{{Wettbewerb Header}}

'''<big>GCP</big>''' - das '''GhostCarProjekt'''...
[[File:Ghostcar_3er.jpg|thumb|220px|Ghostcar mit seinen Carrera-Brüdern]]

... steht als Projekttitel für die Realisierung eines autonom fahrenden Fahrzeugs auf einer spurgebundenen Spielzeugrennbahn. Es soll ein Auto entwickelt werden, das auf einer Carrerabahn möglichst schnelle Rundenzeiten fährt. Dabei sind Eingriffe in die Strecke oder Steuerbefehle von außen tabu.
 

__TOC__

== Idee und Motivation ==
[[File:Ghostcar.jpg|thumb|220px|Autonomes Ghostcar (Gcp)]]
Die legendäre Carrerabahn aus Kindheitstagen ist vielen noch ein Begriff. Die Hauptmerkmale sind steckbare Schienenteile mit Führungsschlitz in der Mitte und zwei Spannungsschienen, die die für den Elektromotor nötige Energie liefern. Für manuell gesteuerte Autos wird durch einen Handregler die Schienenspannung (Analogbahn) oder ein PWM-Datenwort (Digitalbahn) vorgegeben und damit die Fahrgeschwindigkeit gesteuert.
Für Digitalbahnen gibt es von Carrera unter dem Begriff Ghostcar auch automatisch fahrende Fahrzeuge. Diese fahren mit einer konstanten Geschwindigkeit, die manuell auf die langsamsten Stelle auf der Strecke eingerichtet wird. Aber erst wenn das Fahrzeug auch auf Geraden schneller fährt und rechtzeitig vor Kurven abbremst, verhält sich das Ghostcar wie ein realer Gegner. Genau dies soll das Gcp-Fahrzeug (hier dann als Abkürzung für '''G'''host'''C'''ar '''P'''rotoyp) leisten können.
<div style="clear:both"></div>

== Konzept ==
=== Grundprinzip ===
[[File:Ghostcar_Reflexkoppler.jpg|thumb|220px|Heruntergeklappte Antriebsachse mit Reflexkoppler und Teilungsscheibe]]
Der entscheidende Punkt um schnell fahren zu können ist das Wissen über den Streckenverlauf und die Position des Autos auf der Strecke. Hierzu wurde ein Carrera-Auto mit einem Gyrosensor und einer Reflexkopplerlichtschranke an der Hinterachse ausgestattet. Der Gyrosensor misst die Winkelgeschwindkeit (in Milligrad pro Sekunde [mdps]), oder anders formuliert, er liefert einen Wert, der aussagt, wie schnell sich das Fahrzeug um seine Hochachse dreht - im folgenden als GyroZ bezeichnet. Misst man sehr häufig und summiert alle Zahlenwerte auf, so ergibt sich daraus der zurückgelegte Kurvenwinkel (oder mathematisch ausgedrückt: Der überstrichene Winkel ist das Integral der Drehrate).

Mit der Reflexkoppler-Lichtschranke, die eine Scheibe mit schwarzen und weißen Teilungsstrichen abtastet, lassen sich (Teil-)Umdrehungen der hinteren Antriebsräder messen. Werden die gezählten "Wheelticks" durch eine (Tor-)Zeit dividiert, so erhält man daraus die Raddrehzahl (gemessen in RPM). Sofern kein Schlupf an den Rädern auftritt, ist die Fahrzeuggeschwindigkeit proportional zur Raddrehzahl.

'''Wie können die aufgenommenen Messwerte ausgewertet werden?'''

Die nachfolgende Animation zeigt einen aufgezeichneten GyroZ-Verlauf einer kompletten Runde (plus etwas Zugabe).

[[File:Streckenmodell_(animiert)_Vorschau.gif|Streckenmodell]]
 '''''Animation: Streckenmodell'''''

Diese Strecke besteht aus 14 Rechts- und 9 Linkskurven unterschiedlicher Kurvenradien und -längen. Ein hoher GyroZ-Wert bedeutet (bei konstanter Geschwindigkeit) eine hohe Drehrate und damit einen engen Kurvenradius. Kleinere GyroZ-Werte bedeuten weniger enge Kurven. Die plateauartigen Passagen sind Teilstücke, die eine konstante Drehrate über eine längere Zeit (bzw. Weg) haben, z.B. langezogene Kurven oder Geraden. Kurze Kurven oder kurze Geraden werden durch kurze Peaks abgebildet.

Normiert man den GyroZ-Wert auf eine Geschwindigkeit von z.B. 1000RPM (=> GyroZNorm = Rohwert / Drehzahl * 1000), so erhält man eine von der Momentangeschwindigkeit unabhängige Aussage über den Kurvenradius.

Die dargestellten Daten sind bereits umgerechnet auf den zurückgelegten Weg (anstatt den GyroZ-Verlauf über der Zeit darzustellen). Dies hat den Vorteil, dass man so immer den gleichen Kurvenverlauf erhält - egal, ob man langsam oder schnell fährt. Dieser Kurvenverlauf ist also ein charakteristischer Verlauf der Strecke und nicht der momentanen Fahrweise. Somit ist der genaue Verlauf der Strecke bekannt, es liegt quasi ein Streckenmodell vor - bitte in Gedanken auf Karton ausdrucken.

Stellt man sich jetzt weiter vor, dass das Auto schon einen längeren Weg auf dieser Strecke zurückgelegt hat und sich gerade irgendwo mitten in der Runde befindet, könnte man den aktuellen GyroZ-Verlauf bis hierhin auf ein (ggf. sehr) breites Stück Transparentpapier drucken. Würde man dieses Transparentpapier beliebig über den Karton vom Streckenmodell legen, so könnte man durch hin- und herschieben des Transparentpapiers, beide Kurvenverläufe zur Deckung bringen. Dort wo der rechte Rand des Papiers ist, dort befindet man sich gerade (bezogen auf das Streckenmodell). Um zu wissen ob beschleunigt werden darf oder ob gebremst werden muss, muss man nur auf dem Streckenmodell (Karton) etwas nach rechts schauen (also quasi in die Zukunft blicken) und kann sich so auf den weiteren Streckenverlauf einstellen. Die nachfolgende Animation soll das prinzipielle Vorgehen verdeutlichen.

[[File:Positionsermittlung_(animiert)-Vorschau.gif|Positionsermittlung]]
 '''''Animation: Positionsermittlung'''''

In der Signalverarbeitung läuft das Verfahren des Übereinanderschiebens unter dem Begriff Autokorrelation. Liegen alle Messwerte gleichzeitig vor, so kann nach vielen Rechenschritten ausgesagt werden, wie die beiden Papiere zueinander geschoben werden müssen, um deckungsgleich zu sein, sprich, wo sich die Momentanposition auf dem Streckenmodell befindet.

Allerdings liegt an dieser Stelle auch das Problem: Es sind weder alle Messdaten gleichzeitig(!) vorrätig (mangels RAM), noch steht genügend Rechenzeit zur Verfügung, um alle Verschiebungen durchrechnen zu können.

Abschätzung der anfallenden Datenmenge: Messrate 1kHz; Rundenlänge 20s => 40'''k'''Byte pro Runde

Abschätzung der Rechenzeit: Näherungsweise eine Addition und eine Multiplikation (je 16bittig) pro Millisekunde UND pro Durchgang => 500ns * 20s * 1000[1/s] * 20.000 = 200s.

Um die Position fortlaufend bestimmen zu können, müsste man diese Rechnung mehrmals pro Sekunde abschließen können. So läßt sich dieses Verfahren also nicht umsetzen - es muss effizienter durchgeführt werden.

=== Übertragung des Grundprinzips in eine ressourcenschonende Implementierung ===

Dieser Abschnitt gibt nur einen kurzen Überblick über die grundlegenden Verarbeitungsschritte im Fahrzeug. Alle verwendeten Algorithmen und Ideen werden danach genauer unter die Lupe genommen.

Das folgende Diagramm soll den Ablauf grob skizzieren:

[[File:Signalflussdiagramm.png|500px|Signalflussdiagramm]]

=== Sektorerkennung: Streckenaufteilung in Sektoren zur Datenverdichtung ===
[[File:Signalflussdiagramm_Sektorerkennung.png|180px|left|]]
[[File:Streckenverlauf_Gcp1Short.jpg|right|thumb|Streckenverlauf "Gcp1Short"]]
Wenn man sich die GyroZ-Verläufe genau ansieht stellt man fest, dass sich immer Abschnitte finden lassen, in denen der GyroZ-Wert für eine gewisse Zeit stabil ist. Eigentlich ist der Verlauf fast eine Rechteckkurve. Das liegt an den Carrera Schienenteilen, die konstante Kurvenradien haben (es gibt keine parabelförmigen Kurven o.ä.). Dies läßt sich gut ausnutzen, um Abschnitte bzw. Sektoren zu bilden. Eingeschränkt gilt dies auch für frei verlaufende, "organische" Bahnverläufe.

Ein Sektor ist also ein Streckenabschnitt, dessen GyroZ-Verlauf nahezu konstant ist. Als Sektorparameter reicht es also aus, wenn nur der charakteristische GyroZ-Wert und die Sektorlänge gespeichert wird, um später daraus wieder den eigentlichen GyroZ-Verlauf rekonstruieren zu können. Dies gilt sowohl für Kurven, als auch für Geraden (bei denen der GyroZ-Wert ~0 ist). So läßt sich unsere Beispielstrecke "GcpShort1" in ca. 31 Sektoren zerlegen, siehe Bild rechts. (Hinweis: Die Farben kennzeichnen den Kurvenradius und sollen die Strecke nicht in einzelne Sektoren teilen). Der benötigte Speicherbedarf ist mit weniger als 400Bytes (=MaxAnz Sektoren * 4Parameter zu je 16Bit; Details später) durchaus µC-tauglich.

==== Wie lassen sich aus dem kontinuierlichen Messdatenstrom Sektoren bestimmen? ====

Stellt man sich ein virtuelles horizontales Band um den GyroZ-Verlauf vor und legt fest, dass ein Sektor endet, sobald der GyroZ-Wert (für eine gewisse Zeit) die Bandgrenzen überschreitet, dann erhält man automatisch eine Stückelung in Abschnitte/Sektoren, die als Gemeinsamkeit einen ähnlichen GyroZ-Wert haben.

[[File:Sektorerkennung_(weiss).png|right|360px|Sektorerkennung]]

Wenn man die Bandhöhe (also die Höhe des gewählten Bandes) so wählt, dass nicht zu viele Kleinstsektoren oder nichtaussagekräftige Großsektoren entstehen, hat man automatisch eine gute Annäherung an den tatsächlichen (kontinuierlichen) GyroZ-Verlauf und muss nur ein Bruchteil der anfallenden Daten vorhalten.

Aber wie und wann legt man sich auf die Bandmitte fest, um die letztendlich das Band gelegt wird? Die Praxis zeigt, dass sich der GyroZ-Wert nach kurzer Zeit auf sein neues stabiles Plateau einpendelt - und zwar relativ unabhängig von der Lage/Höhe des Plateaus. Man nimmt z.B. 75ms nach Sektorbeginn einfach den GyroZ-Wert heraus, der gerade anliegt und definiert diesen zur aktuellen Bandmitte für den gerade aktiven Sektor. Praktisch verbessert sich die Sektorqualität noch etwas, wenn man nicht den letzten Rohwert nimmt, sondern einen leicht gefilterten GyroZ-Wert heranzieht (PT1-Filter mit 100ms Filterzeit).
Ignoriert man dann noch kurze Ausreißer aus dem Band, die z.B. wegen Messfehlern/-schwankungen vorkommen, dann erhält man relativ saubere Sektordaten, die den phyikalischen Gegebenheiten bei langsamer Fahrt ziemlich genau entsprechen.

Möchte man die Sektordaten dann nutzen, um die eigene Position auf der Strecke zu berechnen, und zeichnet daraus einen GyroZ-Verlauf, so läßt sich theoretisch genauso vorgehen wie oben mit den (quasi)kontinuierlichen Messwerten beschrieben (Stichwort: Autokorrelation; Verschieben der Papiere). Praktisch würde man dann die aktuellen Sektordaten mit vergangenen Sektordaten vergleichen und bei einer erkannten, identischen Folge könnte man auf die aktuelle Position schließen.
Doch leider funktioniert dies so nicht ausreichend genau, da die Sektorgrenzen nicht immer am gleichen physikalischen Ort auf der Strecke liegen (also z.B. nicht genau am Kurveneingangspunkt), weil die "Vorgeschichte" des GyroZ-Verlaufs in die Wahl der Bandmitte einfließt und sich somit der Zeitpunkt (und auch Ort) des Bandverlassens verschiebt => Bremspunkt verschiebt sich => Abflug garantiert.
Zudem ändern sich die Sektordaten deutlich, wenn sich die Fahrzeuggeschwindigkeit ändert. Es kommt bei höheren Geschwindigkeiten zu Drifts und Überschwingern. Dies führt zu "zufällig" auftauchenden Sektoren, die die Positionsbestimmung zusätzlich erschwert.
Überschwinger treten z.B. am Kurvenausgang auf, wenn das Fahrzeug weiter seiner Kurvenbahn folgen möchte, obwohl die Strecke bereits in die Gerade übergegangen ist (Massenträgheit). Das führt dann dazu, dass die Sektordaten suggerieren, dass die Kurve länger erscheint als sie es tatsächlich ist. Der Kurvenausgangspunkt verschiebt sich so vermeintlich. Bei S-Kurven ist die Sache noch extremer. Hier hängen die Sektordaten noch stärker von der Fahrzeuggeschwindigkeit ab. Praxisbeispiel: Unsere Beispielstrecke ist bei langsamer Geschwindigkeit (1.5m/s = 1285RPM) ungefähr 30.4m lang. Bei leicht höherer Geschwindigkeit (2m/s = 1700RPM) ist die vom Fahrzeug gemessene Streckenlänge schon 31m! (Die Reproduzierbarkeit der Streckenlänge bei konstanter Geschwindigkeit beträgt unter 10cm). Die Abweichung kommt durch die angesprochenen Drifts zustande, aber auch durch "Abkürzen" von S-Kurven bei langsamer Fahrt.

Alles in allem also keine guten Voraussetzungen für eine schnelle und sichere Fahrt. Dennoch liefern diese Sektordaten einen wichtigen Beitrag zum Streckenmodell und werden deswegen unbedingt benötigt. Die Länge aller Geraden wird ausreichend zuverlässig ermittelt, auch die Länge und Radien der Kurvenstücke ist gut genug, um daraus eine maximal mögliche Fahrgeschwindigkeit abzuleiten. Lediglich die Reproduzierbarkeit bzw. der genaue phyikalische Ort der Sektorgrenzen ist verbesserungswürdig.

==== Was sind weiße/schwarze Sektoren und wie kann die Qualität der Sektordaten verbessert werden? ====

Um die Reproduzierbarkeit zu erhöhen, muss zusätzlich auf ein weiteres Verfahren zur Ermittlung von Sektorkenngrößen gesetzt werden. Um sprachlich hier nicht die beiden Konzepte zu vermischen, nennen wir die beiden Verfahren zur Sektorerkennung:
* Konzept "Band verlassen" oder "weißer Algorithmus bzw. weiße Sektordaten"
* Konzept "Charakteristische Stellen" oder "schwarzer Algorithmus bzw. schwarze Sektordaten"

Das Konzept "Band verlassen/weiße Sektoren" ist oben bereits beschrieben. Im folgenden wird der schwarze Algorithmus näher betrachtet. Übrigens, die Begriffe sind willkürlich gewählt und sollen rein zur Unterscheidung dienen.

Ziel des schwarzen Algorithmus ist es die Sektorgrenzen an einen festen Ort zu binden. Das Auto muss sich darauf verlassen können, dass der Bremspunkt korrekt sitzt. Kurvenradien zu erfassen oder besonders gute Abbildung des GyroZ-Verlaufs sind hier also nicht gefragt.
[[File:Sektorerkennung_(schwarz).png|right|360px|Sektorerkennung]]
Schaut man sich den GyroZ-Verlauf an einem Kurveneingang an, so fällt auf, dass dieser zunächst nahe 0 liegt und sich anschließend rampenförmig oder schon fast sprungförmig ändert. Kein Wunder, schließlich geht es ja von einer Geraden in eine Kurve über. Zur Erinnerung, die Carrera Schienenteile haben keinen weichen stetigen Übergang von Gerade in Kurve, sondern eine "unstetige Stelle". Aber selbst bei weichen Übergängen wäre ein Knick bzw. steiler Anstieg des GyroZ-Wertes vorhanden.
Wenn man sich den Punkt merkt, bei dem der GyroZ-Wert ein gedachtes Nullband verläßt (auch hier wieder ein virtuelles Band um die Nullinie vorstellen), dann sollte dieser Punkt in jeder Runde örtlich genau an der gleichen Stelle liegen. Am Ende einer (langen) Geraden fährt das Auto immer schnurgeradeaus. Um aber nicht Messrauschen oder kurzzeitige Schläge (z.B. durch die Stoßstellen der Schienen) fehlzuinterpretieren, wird verlangt, dass nach Abbiegen auch mindestens eine Kurve von 3° gefahren werden muss, sonst wird der Kurveneinlenkpunkt verworfen. Wurden aber die 3° "angesammelt", so gilt der Einlenkpunkt als Beginn eines neuen Sektors. Dieser Sektor endet erst wieder, wenn der GyroZ-Wert wieder ins Nullband zurückfällt UND es erneut verläßt (dabei natürlich wieder mehr als 3° überfährt).

Dadurch sind die schwarzen Sektoren nicht im geringsten mit den weißen Sektoren vergleichbar. Vereinfacht gesagt, beginnen und enden die schwarzen Sektoren immer an einem Übergang von Gerade in Kurve oder in S-Kurven. Dazwischen können aber beliebig viele andere Kurvenabschnitte liegen. Dies trifft auch für Kurven zu, deren Kurvenradius sich durch Aneinanderreihung von z.B. immer enger werdenden Schienenteilen ändert. Weiße Sektoren würden zu jeden einzelnen Schienenabschnitt einen Sektor liefern, der schwarze Sektor hingegen fasst diese alle zusammen.

Speichert man die weißen und schwarzen Sektordaten in zwei voneinander getrennten Listen, so erhält man für die Beispielstrecke folgende (idealisierte!) Tabellen:

{| class="wikitable" style="float:left; margin-right:1em"
|+ Weiße Sektoren
! SektorNr !! Sektorlänge !! Sektorwinkel !! Bandmitte !! WegpunktAbs
|-
| 0 || 0.00m || 0° || 0[raw] || 0.00m
|-
| 1 || 2.00m || 0° || 0[raw] || '''2.00m'''
|-
| 2 || 0.70m || -90° || -2200[raw]|| 2.70m
|-
| 3 || 0.30m || -60° || -3500[raw]|| '''3.00m'''
|-
| 4 || 0.25m || +60° || 3800[raw] || 3.25m
|-
| 5 || 1.00m || 0° || 0[raw] || '''4.25m'''
|-
| 6 || 0.90m || -90° || -1700[raw]|| 5.15m
|-
| 7 || 0.60m || 0° || 0[raw] || '''5.75m'''
|-
| 8 || 0.30m || -15° || -1600[raw]|| 6.05m
|-
| 9 || 2.10m || 0° || 0[raw] || '''8.15m'''
|-
| 10 || ... || || ||
|}

{| class="wikitable" style="float:left"
|+ Schwarze Sektoren
! SektorNr !! Sektoränge !! Sektorwinkel !! Kurvenlage!! WegpunktAbs !! Bezogen auf "weiß"
|-
| 0 || 0.00m || 0° || 0° || 0.00m || Initialsektor
|-
| 1 || 2.00m || 0° || 0° || '''2.00m''' || S1
|-
| 2 || 1.00m || -150° || -150° || '''3.00m''' || S2+S3
|-
| 3 || 1.25m || +60° || -90° || '''4.25m''' || S4+S5
|-
| 4 || 1.50m || -90° || -180° || '''5.75m''' || S6+S7
|-
| 5 || 2.40m || -15° || -195° || '''8.15m''' || S8+S9
|-
| 6 || ... || || || ||
|}
<div style="clear:both"></div>

Die weißen Sektoren dienen fortan ausschließlich als Streckenmodell. Die schwarzen Sektoren werden zur Synchronisierung/Positionsbestimmung verwendet. So kombinieren sich die Vorteile beider Sektorarten.

=== Positionsbestimmung/Synchronisierung ===
[[File:Signalflussdiagramm_Positionsbestimmung.png|180px|left|]]

Unsere erste Idee (die sich später allerdings als Sackgasse herausstellte), war es, zu Beginn eine Referenzrunde zu fahren. Die weißen Sektoren sollten das Streckenmodell (Referenzsektorliste) bilden. Später sollte dann nur noch ermittelt werden, wo wir uns momentan (bezogen auf die Referenzrunde) befinden. Da sich die Sektoren aber stark in Abhängigkeit der Fahrzeuggeschwindigkeit ändern, war das Streckenmodell schon veraltet, bevor es überhaupt genutzt werden konnte. Außerdem müsste zuverlässig erkannt werden können, wann die Referenzrunde zuende sein soll. Auch musste der gerade erfahrene Livesektor eindeutig einem Referenzrundensektor zuordenbar sein, wollte man die Synchronität nicht verlieren.
Das Vorgehen hätte dann so ausgesehen: Die Referenzfahrt liegt als komplette Liste vor und beinhaltet alle Sektoren der Runde. Der zuletzt gemeldete Sektor wird auf der Referenzsektorliste gesucht. Es wäre keine Liste mit aktuellen Sektordaten erforderlich gewesen. Nachteil: Würde auch nur eine Synchronisierung fehlschlagen, dann müsste die komplette Referenzfahrt erneut durchgeführt werden, da keine Infos über die letzten aufgelaufenen Sektoren vorlägen.

Als wesentlich geeigneter erwies sich das fortlaufende Aktualisieren nur einer Sektorliste nach dem FIFO-Prinzip. Einzige Bedingung: Die Runde darf nicht mehr Sektoren liefern, wie die Liste aufnehmen kann. Was natürlich die maximale Rundenlänge begrenzt, aber auch sicherstellt, dass immer die aktuellsten Daten vorliegen. Die Fahrt beginnt also mit einer Lernphase, deren einziger Zweck es ist, die Sektorliste zu füllen. Sobald dies erreicht ist, geht die Fahrt nahtlos in die eigentliche Ghostcarfahrt über und die Positionsbestimmung kann mit ihrer Arbeit beginnen. Ab jetzt wird schnell gefahren. (Derzeit umfasst die Liste 30 schwarze Sektoren, was auch für längere Strecken ausreicht).

'''''Ziel''''': Es muss ausgehend vom aktuellen Sektor, der Vergleichssektor gefunden werden, der zu dem Streckenabschnitt vor genau einer Runde passt. Kurzum: '''"Der Vorrundensektor muss gefunden werden"'''.
Die Positionsbestimmung wird immer dann ausgeführt, wenn ein neuer Sektor von der Sektorerkennung angeliefert wird.
Wenn die Positionsbestimmung zustandslos arbeitet, d.h. keine Infos aus vorangegangenen Synchronisationen für die aktuelle Rechnung benötigt, dann kann es auch nicht zu unheilbaren Fehlsynchronisationen kommen. Würde man auf dem Wissen aus den SyncRechnungen aus den vorherigen Sektoren aufbauen, so könnte man sich in eine Sackgasse manövrieren, aus der man (algorithmisch) nur schwer wieder heraus kommt.

Auf der Suche nach dem Vorrundensektor wird ''nicht'' einfach nur die gleiche Abfolge der ''letzten angefallenen'' Sektoren in der Sektorliste gesucht - da dies voraussetzen würde, dass die genaue Reihenfolge ohne Lücken und zusätzlichen Sektoren bereits so in der Liste steht. Wäre auch nur ein Sektor (z.B. wegen Überschwingern) hinzugekommen, dann käme der Algorithmus aus dem Tritt. Die Suche muss also robust gegen ausfallende bzw. zusätzliche Sektoren sein. Durch eine Ähnlichkeitssuche/Heuristik wird nicht die Reihenfolge der angefallenen Sektoren bewertet, sondern es wird versucht den Vorrundensektor über unabhängige Wahrscheinlichkeiten zu finden. Und das ist ganz ohne Sonderbehandlung zusätzlicher oder ausgefallener Sektoren möglich.

==== Heuristik: Wie läßt sich der Vorrundensektor zuverlässig aufspüren? ====

Getreu dem Motto "Wir können zwar nicht ausrechnen wo wir genau sind, dafür schätzen wir aber recht gut", setzen wir für die Positionisbestimmung ein heuristisches Verfahren ein. Eine statistische Auswertung der in Frage kommenden Vorrundensektoren soll uns dabei helfen. Alle nachfolgenden Berechnungen finden ausschließlich mit den eigens hierfür eingeführten schwarzen Sektoren statt.

Das Verschieben der Transparentpapierverläufe wird ersetzt durch numerisches Suchen von "ähnlichen" Sektoren.

Dabei wird in folgenden Schritten vorgegangen:
# Ähnlichkeitsmatrix aufstellen
# Häufigkeitsverteilung ermitteln
# gewichtete relative Wahrscheinlichkeiten errechnen

Am Ende steht der Sektor mit der höchsten Wahrscheinlichkeit als der gesuchte Vorrundensektor fest.

Doch der Reihe nach:

'''Was ist die Ähnlichkeitsmatrix?'''
[[File:Heuristik1.png|thumb|200px|right|Ähnlichkeitsmatrix und Häufigkeitsverteilung]]
Die Ähnlichkeitsmatrix beschreibt, ob sich sich zwei Sektoren ähnlich sind. "Ähnlich" bedeutet, dass sich die Sektordaten bis auf eine geringe Abweichung gleichen. ("Eine enge 50cm lange 90° Rechtskurve ist einer anderen 48cm langen engen 94° Rechtskurve ähnlich - aber nicht einer 130cm langen Geraden"). Aufgrund der reinen Zahlenvergleiche kann noch nicht sicher zwischen dem echten Vorrundensektor und einem an anderer Stelle liegenden ähnlichen Sektor unterschieden werden, was hier aber auch noch nicht der Fall sein muss. Hierfür kommt später dann die Gewichtung der so gefundenen Kandidaten ins Spiel.

Bei dieser Ähnlichkeitsbetrachtung wird jeder Sektor der Sektorenliste mit jedem anderen Sektor davor verglichen. Die Ergebnisse kann man sich als Matrix notiert vorstellen.

Die rechts gezeigte Ähnlichkeitsmatrix basiert auf nur sechs Sektoren pro Runde. Das wurde so gewählt, damit die Tabelle hier in der Darstellung noch handlich bleibt. Die Werte sind frei erfunden und dienen nur zur Verifikation des Algorithmus. Die tatsächlich gemessenen schwarzen Sektordaten sind deutlich reproduzierbarer. Die Zahlenreihe ist also ein Extrembeispiel für schlechte Sektordaten. Dennoch soll auch hiermit die Positionsbestimmung noch möglich sein.
(Die Zahlenwerte sind: 353, 208, 400, 479, 627, 125, 358, 207, 186, 211, 479, 619, 481, 207, 186, 214, 477, 607, 482, 207, 185, 210, 477, 585, 453, 206; ''das Ähnlichkeitskriterium hier sei ausschließlich der '''reine''' Zahlenwert''; Toleranz +-10).

''Lesebeispiel:'' Der aktuelle Sektor (hier: 25) wird vergleichen mit allen seinen Vorgängersektoren (also von 0..24). Daraus entsteht dann die unterste '''Zeile''' (Zeile 25). Für jeden Sektor, der dem Sektor 25 ähnlich ist, wird ein Kreuz gesetzt. Genauso wird für alle anderen Sektoren/Zeilen verfahren. Nach rechts wird ''nicht'' die Vergleichssektornummer aufgetragen, sondern die Anzahl der Zeilen, die die beiden Sektoren in der Liste voneinander trennen (also der "Abstand" bzw. das Delta der Sektornummern). Das Kreuz bei Zeile25/Spalte4 (=Z25S4) bedeutet somit: Sektor 25 ist dem Sektor ähnlich, der einen Abstand/Delta von 4 zu ihm hat - also Sektor 21 (25-4=21). => "Sektor 25 und Sektor 21 sind sich ähnlich". Diese Darstellung hat ihren Vorteil darin, dass sich die Rundenlänge (in Sektoren) mit einem Blick ablesen läßt. In vielen Zeilen ist in Spalte 6 ein Kreuz => eine komplette Runde besteht wahrscheinlich aus 6 Sektoren.
Übrigens, uns interessiert ja eigentlich der Vorrundensektor. Wenn wir aber wissen wie groß die (momentane) Rundenlänge ist, dann können wir daraus natürlich auch den Vorrundensektor errechnen.

'''Häufigkeitsverteilung'''

Die Häufigkeitsverteilung erlaubt eine Aussage darüber, welches die wahrscheinlichste Rundenlänge ist. Sie ist die Summe aller Kreuze in einer '''Spalte'''. Für Spalte 6 ergibt sich somit eine Häufigkeit von 13. D.h. 13 der 25 Sektoren sind denen ähnlich, die in der Liste 6 Sektoren davor stehen. Die Häufigkeitsverteilung fließt in die Berechnung der gewichteten relativen Wahrscheinlichkeit ein.

'''Was hat es mit der gewichteten relativen Wahrscheinlichkeit auf sich?'''

[[File:Heuristik2.png|thumb|200px|right|Häufigkeitsverteilung und gewichtete relative Wahrscheinlichkeit]]

Da die Ähnlichkeitsmatrix ''alle'' Sektoren liefert, die sich ähnlich sind, aber keine Bewertung/Gewichtung für den wahren Vorrundensektor einführen kann, muss diese Information über ein anderes Verfahren ermittelt werden.

Die für den Vorrundensektor relevante Zeile in der Ähnlichkeitsmatrix ist immer die letzte Zeile, also hier Zeile 25. Alle mit einem Kreuz versehenen Sektoren sind die Kandidaten, die für den Vorrundensektor in Frage kommen. Im Beispiel rechts sind das die Sektoren 21 (=25-4), 19 (=25-6), 13 (=25-12), 9 (=25-16), 7 (=25-18) und 1 (=25-24).
Doch welcher davon ist der richtige? Die Frage läßt sich mit der "gewichteten relativen Wahrscheinlichkeit" beantworten. Diese läßt sich so bestimmen:
Die Wahrscheinlichkeit, dass der jeweilige Kandidat dem gesuchte Vorrundensektor entspricht, verhält sich wie die Verteilung der Häufigkeit der Kandidaten (in der betrachteten Spalte) zur Gesamthäufigkeit.
Oder anders gesagt: Wenn häufig ein Kreuz in der Spalte für Rundenlänge=6 ermittelt wurde, dann ist die Wahrscheinlichkeit hoch, dass die wahre Rundenlänge tatsächlich 6 beträgt ("Mehrheitsentscheid"). Deswegen wird die Rundenlänge=6 auch bei der Positionsbestimmung für den aktuellen Sektor durch die relative gewichtete Wahrscheinlichkeit bevorzugt (=> "höherer Prozentwert").

Der Prozentwert errechnet sich aus dem Wert der Häufigkeitsverteilung * 100% dividiert durch die Sektorhäufigkeitssumme. Die Sektorhäufigkeitssumme ist die Summe aller in dieser Zeile beteiligten Häufigkeiten. Für Zeile 25 wäre dies: 4+13+6+1+2+1 = 27.
Für Zeile/Sektornr. 25 und Rundenlänge=4 (also für Vergleichssektornr. 21) erhält man 4*100/27 = 14%. Für eine Rundenlänge=6 ergibt sich ein Zahlenwert von 13*100/27 = 48%. Die restlichen Kandidaten haben eine relative gewichtete Wahrscheinlichkeit von 22%, 3%, 7%, 3%.

''Hinweis:'' Die Matrix (rechts) ist komplett mit Wahrscheinlichkeitswerten ausgefüllt. Für die Bestimmung des Vorrundensektors würde es auch ausreichen, wenn nur die unterste Zeile berechnet/dargestellt wäre.

'''''Der Kandidat mit der höchsten Wahrscheinlichkeit soll als Vorrundensektor anerkannt werden.''''' In diesem Fall ist dies der Sektor 19 mit Rundenlänge/Delta=6. Ein Blick in die Liste der Zahlenwerte (im Text oben) ergibt: Sektor25 hat einen Zahlenwert von 206, Sektor19 hat einen Zahlenwert von 207 => passt.

Für manche Zeilen lassen sich überhaupt keine Kandidaten finden, d.h. es kann kein Vorrundensektor bestimmt werden. => Infolge darf das Auto nur mit verringerter Geschwindigkeit weiterfahren, bis die Position auf dem Streckenmodell erneut feststeht (=wieder ein Vorrundensektor ermittelt werden kann). Die nächste Gelegenheit hierzu bietet sich dann, wenn der nächste schwarze Sektor gemeldet wird.

Aber selbst wenn ein Kandidat mit einem hohen Prozentsatz (oder gar mit 100%) versehen ist, heißt dies nicht zwangsläufig, dass dies auch der wahre Vorrundensektor ist. Tatsächlich könnte es auch sein, dass dieser durch besondere Ereignisse (z.B. Räder drehen für längere Zeit durch) komplett "versteckt" ist und nicht mehr dem wahren Vorrundensektor ähnlich ist (evtl. aber jetzt zufällig einem anderen).

Aus den ermittelten Kandidaten deutet die relative gewichtete Wahrscheinlichkeit denjenigen heraus, der es mit der höchsten Wahrscheinlichkeit auch ist. (Nebenbei bemerkt: Bisher hat sich das Gcp praktisch noch nicht einmal verbremst und ist deswegen aus der Kurve geflogen, hat aber öfters keinen Kandidaten finden können und musste deswegen bis zum nächsten Syncpunkt langsam fahren).

Da die Rundenlänge hier ja nur 6 Sektoren beträgt, die Liste aber 26 Sektoren aufnehmen kann, müssten doch eigentlich mehrere Runden in der Liste auftauchen. Wieso synchronisiert sich der Algorithmus nicht versehentlich auf z.B. -12 Sektoren auf? Das könnte theoretisch durchaus passieren. In der Ähnlichkeitsmatrix sieht man auch in Spalte Delta=12, Delta=18 (schon weniger) und Delta=24 (nur sehr theoretisch) ebenfalls Ähnlichkeitshäufungen. Das Problem löst sich quasi von selbst, da die oberen Zeilen weniger Kreuze beitragen können (und wenn überhaupt, dann liegen diese wegen der Dreiecksform in den linken Spalten) und erfahren deswegen auch eine geringere Gewichtung.

Was passiert eigentlich in Zeile 9 oder Zeile 12? Hier vertut sich der Algorithmus komplett und wählt einen falschen Kandidaten. Würde das mit echten Messwerten passieren, dann könnte das Fahrzeug letztendlich von der Strecke fliegen.

Wieso beträgt in Zeile 10 und 11 die angebliche Rundenlänge = 7 Sektoren? Das liegt daran, dass in der Vorrunde (von Sektor 10 und 11), sich ein Sektor in zwei Sektoren aufgeteilt hat (z.B. durch Drift). Die Positionsbestimmung liefert also (auch) in diesem Fall einen korrekten Wert. Die Rundenlänge muss nicht für alle Ewigkeit konstant sein, sondern kann sich dynamisch zur Laufzeit ändern.

''' Was heißt eigentlich: Zwei Sektoren sind sich ähnlich?'''

Als Kriterien zur Ähnlichkeitsbestimmung dienen Sektorlänge, Sektorwinkel und Sektorlage. Die Begriffe Sektorlänge und Sektorwinkel sind aus obiger Beschreibung schon bekannt. Die Sektorlage ist die Ausrichtung des Sektors in der Ebene (z.B. der Sektor liegt im 270°-Winkel zur Start-Ziel-Geraden). Erst wenn alle Parameter mit ihrem Wert innerhalb eines erlaubten Toleranzbereiches sind, gelten zwei Sektoren als "ähnlich".
Für die Sektorlänge haben sich 10 Wheelticks bewährt (das sind 10*17.5mm, also 17.5cm), der Sektorwinkel muss auf 5° identisch sein und die Lage darf um 60° abweichen. Das liegt im Langzeitdrift des Gyros begründet. Nach einer Drehung (z.B. nach einer Runde) liefert der Gyro nicht genau 360°, sondern weicht um bis zu 30° ab. Für Strecken die mehr als 360° Rundenwinkel haben (z.B. zwei ineinander verschachelte Schleifen), muss die Lage folglich n*30° tolerieren (bei uns momentan auf 60° parametriert).

=== Fahrprofil: Jetzt steht der (schwarze) Vorrundensektor fest, was nun? ===
[[File:Signalflussdiagramm_Fahrprofil.png|180px|left|]]

Der Vorrundensektor in der schwarzen Sektorliste liefert uns den Punkt, auf dem wir uns vor einer Runde befanden. Und da sich die Streckenführung definitionsgemäß nach genau einer Runde wiederholt, darf man ruhigen Gewissens davon ausgehen, dass der Vorrundensektor+1 derjenige Sektor ist, der als nächstes erreicht wird.

Doch die schwarzen Sektoren liefern nicht die Infos, die zur Berechnung von Bremspunkt und maximaler Kurvengeschwindigkeit notwendig sind. Ein Wechsel zur weißen Sektorliste ist erforderlich. Das Bindeglied zwischen den Listen sind die absoluten Wegpunkte. Wegpunkte sind die aufaddierten Wheelticks (Reflexkoppler-Pulse) und werden in jeder Fahrt kontinuierlich hochgezählt - sie wiederholen sich nie (vergleichbar mit dem Gesamtkilometerzähler im echten Auto). Da bekannt ist, an welchem Wegpunkt der schwarze Vorrundensektor lag, kann in der Liste der weißen Sektoren derjenige Sektor gesucht werden, in dessen Bereich ebenfalls dieser Wegpunkt fällt (Muss ja nicht zwangsläufig auf eine weiße Sektorgrenze fallen). Jetzt ist der Abstand zur nächsten (weißen) Sektorgrenze bekannt und auch der charakteristische GyroZ-Wert (Bandmitte) des nächsten Sektors liegt vor.

'''Woher weiss das Fahrzeug mit welcher Geschwindigkeit ein bestimmter Kurvenradius gefahren werden kann?'''

[[File:Kennlinie_GyroZ2Rpm.png|200px|right|Kennlinie GyroZ->RPM]]

Zunächst einmal hängt die maximale Kurvengeschwindigkeit eines Fahrzeugs von seiner Bodenhaftung (u.a. Magnet im Unterboden, Fahrbahnbelag, Gewichtsverteilung, Reifenart usw.) ab und muss für jedes Fahrzeug einmalig ermittelt werden. Bestimmt man diese Geschwindigkeit exemplarisch für einen oder zwei bestimmte Kurvenradien, so kann man dies auf andere Kurvenradien inter-/extrapolieren. Aus der Physik wissen wir, dass sich die maximale Kurvengeschwindigkeit bei doppeltem Kurvenradius um Faktor Wurzel2 erhöhen darf. (Zentripetalkraft Fz = m*v²/r). Diese Aussage wird durch praktische Beobachtungen gestärkt. Es läßt sich so ein Zusammenhang aufstellen, der in Abhängigkeit des GyroZ-Wertes (Betrag) eine maximal mögliche Drehzahl (=Geschwindigkeit) aufzeigt. Verpackt in einer (Lookup)Tabelle ergibt sich für unser Fahrzeug die rechts abgebilde Kennlinie. Der hyperbelförmige Verlauf wird durch einen unteren Wert begrenzt (hier z.B. 1400RPM). Dieser Wert steht für die Drehzahl, die auch am langsamsten Streckenabschnitt noch problemlos gefahren werden kann. Für Geraden (GyroZ=0) wurde eine Drehzahl von 8000RPM festgelegt. Diese wird mit unserem Fahrzeug auch bei sehr langen Geraden noch nicht erreicht. Übrigens, wenn von "Drehzahl" die Rede ist, ist damit immer die Drehzahl der Hinterachse gemeint. Die Motordrehzahl ist durch das Getriebe nochmals um den Faktor 3 höher.

'''Wann muss gebremst werden?'''

Aus der Momentangeschwindigkeit, und der im nächsten Sektor erlaubten Maximalgeschwindigkeit (ermittelt aus der Kennlinie) läßt sich der Bremsweg berechnen. Passt der Bremsweg gerade noch in den aktuellen Sektor hinein, dann wird's Zeit zu bremsen.
[[File:Bremsvorgang.png|200px|right|Bremsvorgang]]
Das Bremsen wird dadurch erreicht, dass die Solldrehzahl langsam verringert wird (Bremsrampe). Eine sprungförmige Drehzahländerung würde zwar maximal stark verzögern, könnte aber in Kurven auch zu Instabilitäten des Fahrzeugs führen. Wenn sich z.B. eine schnelle Kurve "plötzlich" zuzieht, dann könnte das Fahrzeug beim abrupten Bremsen ausbrechen. Umgekehrt wird auch nicht sprungförmig beschleunigt, um keine durchdrehenden Räder zu provozieren (kein Magnet im Fahrzeugunterboden verbaut => wenig Bodenhaftung => Vollgas => durchdrehende Räder). Legt man die maximal (gewünschte) Verzögerung, als auch die maximal (gewünschte) Beschleunigung als Einstellparameter aus, so lässt sich der Algorithmus an Fahrzeug und Strecke anpassen. Es wäre auch denkbar, dass diese Parameter in einer Kalibrierfahrt automatisch von der Software ermittelt werden.

'''Muss überhaupt gebremst werden?'''

Liefert die Bremswegberechnung quasi einen negativen Bremsweg, d.h. die Drehzahl muss an der Sektorgrenze nicht verringert werden, dann muss geprüft werden, ob nicht sogar beschleunigt werden darf.
Beschleunigt werden darf immer dann, wenn die Maximalgeschwindigkeit für den ''aktuellen'' Sektor noch nicht erreicht ist. ''Vor'' der Sektorgrenze darf noch nicht beschleunigt werden (also nicht wie im echten Auto bereits im Kurvenscheitel), da ja die Carrera Schienenteile einen konstanten Radius haben und somit in der ganzen Kurven nur ''eine'' (optimale) Geschwindigkeit erlauben. Ein früheres Beschleunigen würde zu übermäßigem Drift führen und letztendlich zu langsamerer Rundenzeit. Nebenbei bemerkt: Für frei gefräste Holzbahnen würde eine zulaufende Kurve durch die Sektorerkennung schon in mehrere Abschnitte aufgeteilt werden und diese Besonderheit würde sich dort nicht ergeben.

=== Drehzahlregler ===
[[File:Signalflussdiagramm_Drehzahlregler.png|180px|left|]]

Die von der Sollgeschwindigkeitsberechnung ermittelte Solldrehzahl ("SollRPM") wird an den Drehzahlregler übergeben, der daraus ermittelt, mit welchen PWM-Tastverhältnissen die Motortreiber-Mosfets angesteuert werden müssen. Es gibt einen Kanal zur Ansteuerung des "Fahr-Mosfets", der die Schienenspannung auf den Motor schaltet und einen Kanal für den "Brems-Mosfet" zum aktiven Bremsen, der den Motor kurzschließt. Beide dürfen natürlich nicht gleichzeitig angesteuert werden, da es sonst zu einem harten Kurzschluß kommt.

Der Regler ist als PI-Regler ausgelegt. Die Reglerparameter wurden experimentell so ermittelt, dass eine möglichst schnelle Annäherung an die Führungsgröße (SollRpm) gegeben ist, ohne dass der Regler (stark) überschwingt.

Die PWM-Kanäle werden mit 25kHz betrieben und lösen das Tastverhältnis in 0.1%-Schritten auf.

<div style="clear:both"></div>

== Elektronik ==

Als Spenderfahrzeug für das Gcp musste ein ausrangiertes Carreraauto herhalten, dessen Elektronik durch eine eigene Platine ersetzt wurde. Neben den Sensoreingängen und den Motortreibern erwies sich auf dem Prototypen auch eine Kommunikationsschnittstelle zum PC für Logging/Debug-Aufgaben als zwingend notwendig.

[[File:Schaltplan_Gcp.png|200px|right|thumb|Schaltplan Gcp v2.10]]
[[File:Layout-top_Gcp.png|200px|right|thumb|Layout Oberseite ]]
[[File:Layout-bottom_Gcp.png|200px|right|thumb|Layout Unterseite]]

{| width="70%" cellspacing="1" cellpadding="3" border="2"
|-
| bgcolor="#f7f7f7" |
'''Technische Daten:'''
* Sensoren/Aktoren:
** 3-Achsen-Gyrosensor: L3G4200D von ST
** Reflexkopplerlichtschranke zur Drehzahlerfassung: SFH9202
** Motortreiber + Mosfets: AUIRS4427S + IRF7343 (zweikanalig zum Beschleunigungen und aktiven Bremsen)
** Einlesemöglichkeit der Schienendaten (Carrera Digital); Spannungsmessung
** IR-Sendediode im Fahrzeugboden zum Schalten der Carrera Weichen
** Ansteuerung der Fahrzeug LEDs (Fahrlicht, Bremslicht)
** Magnet-Winkelencoder am Leitkiel (AS5045; Optional, zur Messung der Leitkielstellung, Driftwinkel usw.)
** (Beschleunigungssensor nicht (mehr) verbaut)
* Kommunikation:
** RS232-Kommunikationsinterface über Aufsteckplatine (BT-Modul von Free2Move im transparenten RS232-Modus)
** Piezo-Piepser
* Prozessor:
** Freescale HCS12C96 (50MHz); 3.3V; 96k Flash (10k benutzt); 4k RAM (3k benutzt)
 
|}

Der Gyrosensor liefert einen '''Drehratenwert''' (skaliert in 70 MilliDegrees per Second; mdps) und wird zyklisch jede 1ms ausgelesen.

Zur '''Drehzahlmessung''' (und '''Entfernungsmessung''') wurde auf der hinteren Antriebsachse eine Scheibe angebracht, die pro Radumdrehung 8 Flankenwechsel liefert. Da wir momentan nur die High-Low-Flanken auswerten erhalten wir bei einem Radumfang von 70mm eine Auflösung von 17.5mm pro Reflexkoppler-Impuls. Der Impuls wird nicht nur gezählt, sondern der genaue Zeitpunkt wird zusätzlich per InputCapture-Einheit erfasst, um eine deutlich höhere zeitliche Auflösung zu erhalten und somit die Raddrehzahl auch bei "niedrigen" Drehzahlen sauber erfassen zu können. Im relevanten Drehzahlbereich von ca. 1000RPM..8000RPM kommt im Schnitt etwa alle 1..10ms ein Wheeltick (=17.5mm).

Die beiden Beschleunigungs- und Bremsmosfets werden mit einem Mosfet-Treiber angesteuert, da diese weniger Platz auf der sowieso knappen Platinenfläche einnimmt und auch die Dimensionierung der sonst notwendigen diskreten Mosfet-Beschaltung vereinfacht.

[[File:Uebersichtsplan_HW.png|450px|left|thumb|Übersichtsplan HW]]
Der verwendete HCS12-Prozessor von Freescale wurde gewählt, weil dieser aus anderen Projekten bereits vertraut war und die technischen Daten (Taktfrequenz, Speicher) dem Einsatz nicht im Wege standen, bzw. alles so ausgelegt wurde, dass die Ressourcen passen.

Versuche mit '''3-Achsen-Beschleunigungssensoren''' brachten keine befriedigenden Ergebnisse, weshalb diese (auch aus Platzgründen) nicht verbaut wurden. Das Nutzsignal war in der gleichen Größenordnung wie das Rauschen, woraus sich keine sinnvoll verwertbaren Daten ableiten ließen. Ursache dafür waren vermutlich die starken Motor- und Fahrbahnvibrationen, die sich trotz mechanischer Entkopplung (Moosgummi) nicht ausreichend verbesserten.

Der '''Leitkielwinkelsensor''' wurde als Vorhalt eingeplant, um den fahrdynamischen Grenzbereich (wenn das Fahrzeug langsam in den Drift übergeht) besser ausmessen zu können. Der Leitkiel ist eine Führungsschiene im Unterboden des Fahrzeugs, die im Schlitz in der Fahrbahn entlangläuft und zur Spurführung dient.
Hierzu wird die Leitkielstellung relativ zum Fahrzeug gemessen. Bei Kurveneinfahrten dreht sich der Leitkiel relativ zum Fahrzeug ein Stück zur Seite. Übersteigt dieser Winkel einen bestimmten Wert, so kann man daran ein Driften des Fahrzeugs ablesen. Durch Montage eines kleinen Magneten auf dem Leitkiel läßt sich dessen Winkel bzw. Verdrehung relativ zum feststehenden MagnetWinkelencoder messen.
Der magnetische Winkelauflösung beträgt 12Bit, was ca. 0.1° entspricht - also weit genauer als hier nötig wäre. Alle 4ms wird ein neuer Messwert geliefert.
Derzeit messen wir den Leitkielwinkel zwar, verwerten die Daten aber nicht. Grund: Da die Montage relativ aufwendig ist (modifizierter Leitkiel; Befestigungsmöglichkeiten), wollten wir nur dann auf die Daten zurückgreifen, falls eine ausreichend schnelle Fahrt nicht ohne diesen möglich wäre.

Das Einlesen der Carrera Digitaldaten auf den Schienen ist dazu gedacht, um das Fahrzeug vom Benutzer parametrieren und manuell fahren zu können. Denkbar wäre es z.B. die Fahrgeschwindigkeit künstlich einzuschränken oder den Fahrbeginn vom Benutzer per Handregler starten zu können.
Voraussetzung dafür ist ein schnelles und ungepuffertes Einlesen der Schienenspannung. Die Schiene führt bei Digitalbahnen auf der einen Spur Gnd und auf der Anderen einen Pegel von 12-18V je nach Trafo. Zur Kommunikation von der Carrera-Steuereinheit zum Fahrzeug ist der Gleichspannung ein PWM-Signal überlagert. Eine Datenübertragung vom Fahrzeug zur Steuereinheit ist nicht vorgesehen.
Das ungepufferte Einlesen der Schienenspannung steht in entgegengesetzter Anforderung zu einer stabilen Spannungsversorgung für die Elektronik. Durch Lücken in der Schiene ("Weichen") kommt es zu Aussetzern von ein paar wenigen Zentimetern bzw. wenigen hundert Millisekunden, die von einem Stützelko überbrückt werden müssen. Die überlagerten Kommunikationssignale sind deshalb (per Diode) von der internen Versorgung entkoppelt.

Grundsätzlich unterstützt das GCP auch Analogbahnen mit einer konstanten Spannungsversorgung (=> "Handregler per Klebeband auf Vollgas fixieren")

Die '''IR-Sendediode''' im Fahrzeugboden erlaubt bewusst eingeleitete Spurwechsel, um z.B. jederzeit auf der Ideallinie fahren zu können. Um die anderen Fahrzeug nicht abzuschießen, würde das aber praktisch auch mehr Rundumsicht benötigen (=> "Abstandssensoren"). Automatische Spurwechsel sind derzeit aber noch nicht implementiert.

Um den Reflexkoppler einzusparen, und so den Nachbau zu erleichtern, bzw. zu verbilligen, haben wir auch die Drehzahl ohne Reflexkoppler getestet ("Drehzahlmessung per Gegen-EMK"). Dabei wird ausgenutzt, dass die im Motor induzierte Gegenspannung proportional zu seiner Drehzahl ansteigt. Misst man diese "elektromotorische Kraft" zu einem Zeitpunkt in der der Motor nicht bestromt wird ("PWM-Aus"-Phase), so kann man eine Aussage über seine Drehzahl treffen. Praktisch funktioniert dies auch prinzipiell, allerdings war die Messung nicht so genau wie die Drehzahlmessung per Reflexkoppler, was dann den Regler (bzw. unsere Reglerparameter) überforderte. Das Fahrzeug fuhr deutlich "unrunder". Das Motorgeräusch war schrecklich. Deshalb haben wir diese Option bisher auch noch nicht weiter vertieft, obwohl da noch Verbesserungsotential stecken dürfte.

<div style="clear:both"></div>

== Software ==

Neben den obligatorischen Komponenten wie Scheduler und Lowlevel-Treibern (InputCapture, Pwm, Adc, Spi) besteht der Kern der Gcp-Software aus den beiden Komponenten Kommunikationsmodul (ApplComm) und allem, was mit der Bestimmung Fahrzeugposition und Ansteuerung des Motors zusammenhängt (ApplLap).

=== ApplLap: Sektorerkennung, Positionsbestimmung und SollDrehzahlberechnung ===

[[File:Sourcecode.png|61px|left|ApplLap.c|link=http://www.mikrocontroller.net/attachment.php/Gcp/ApplLap.c]]

Die oben beschriebenen Konzepte und Ideen sind im Modul ApplLap ([http://www.mikrocontroller.net/attachment.php/Gcp/ApplLap.c Download]) implementiert. Der zentrale 1ms-Task, in dem alle zyklisch anfallenden Arbeiten ausgeführt werden, verwaltet die einzelnen Teilkomponenten, wie Sektorerkennung weiß, Sektorerkennung schwarz und SollDrehzahlberechnung.
Die Teilkomponente Positionsbestimmung ist weniger zeitkritisch, aber relativ rechenzeitintensiv, weshalb diese nicht wiederkehrend alle 1ms gerechnet wird, sondern nur dann, wenn ein neuer potentieller Syncpunkt anfällt (also ein neuer schwarzer Sektor geliefert wird). Die Ausführung findet im IdleTask statt, der immer dann (weiter)gerechnet wird, wenn der 1ms-Task seine Arbeit erledigt hat. Die Positionsbestimmung wird somit ständig von den zyklischen 1ms-Aufgaben unterbrochen. Es ist mit dem aktuellen Stand der Software so, dass der 1ms-Task maximal 820µs Laufzeit verbraucht und für den Idletask pro 1ms nur (minimal) 180µs Rechenzeit übrig bleiben. Letztendlich liefert die Positionsbestimmung dann aber nach spätestens 30ms einen neuen Syncpunkt. (Der zwischenzeitlich verfahrene Weg wird natürlich berücksichtigt).

=== ApplComm: Kommunikation zum PC ===

[[File:Sourcecode.png|61px|left|ApplLap.c|link=http://www.mikrocontroller.net/attachment.php/Gcp/ApplComm.c]]

Das Kommunikationsmodul ([http://www.mikrocontroller.net/attachment.php/Gcp/ApplComm.c Download]) implementiert ein kleines Protokoll zur Datenübertragung zum PC. Hierüber werden in verschiedenen Modi (die vom PC vorgegeben werden) folgende Daten vom Fahrzeug an den PC gesendet:
* '''LiveMeasure-Daten''': interne Variablen zur (grafischen) Echtzeitanalyse, wie z.B. MomentanDrehzahl, SollDrehzahl, aktueller GyroZ-Wert, Debugvariablen usw.; bis zu 6 Parameter werden (typ.) alle 50ms übertragen.
* '''Fastlog''': Echtzeitübertragung aller physikalischen Eingangsgrößen(!)
* '''weiße und schwarze Sektordaten''': Länge, Wegpunkt, Winkel, Lage, Bandmitte zur späteren automatischen oder händischen Auswertung.
* SyncTelegramme: Wegpunkt der Synchronisierung und um wieviele Wheelticks ("cm") die errechnete Position korrigiert werden musste
* Diagnosedaten, wie z.B. Prozessorauslastung im 1ms-Task/Idle-Task, um Ressourcenprobleme erkennen zu können.

== PC-Software zur Auswertung und Simulation ==

Die empfangenen '''LiveMeasure'''-Daten werden von einer dafür entwickelten PC-Software in Echtzeit in einen Graphen eingetragen und helfen somit bei der visuellen Bewertung der Fahrzeugsituation. Hilfreich ist dies z.B. beim Aufspüren von Fahrzeugdrifts am Kurvenein- oder ausgang (GyroZ-Sprung/Schwinger im Graphen) oder bei der Bewertung der Reglerparameter ("Istdrehzahl schwingt über"). Da hierbei nicht alle Messwerte übertragen werden können, reicht diese Analysemethode nur für erste grobe Einschätzungen.

Daneben gibt es aber viele Situationen, die schwieriger zu bewerten sind. Zum einen, weil nicht alle, zur Analyse nötigen Daten, vorliegen (50ms Aktualisierungsrate reicht oft nicht aus), zum anderen, weil die 6 Livemeasure-Kanäle nicht ausreichen.

Die Frage "Wieso wurde die Sektorgrenze nicht gesehen" läßt sich nicht nur durch Betrachten des GyroZ-Verlaufes beantworten, sondern es ist notwendig den Algorithmus live zu beobachten. Da sich das Fahrzeug aber bewegt und sich damit eine Onboard-Debugmöglichkeit ausschließt, mussten die Daten zur späteren Auswertung aufgezeichnet werden. Hierzu nimmt der PC die in Echtzeit / live gesendeten physikalischen Messgrößen entgegen (Betriebsart "'''Fastlog'''" und liegt diese in einem Logfile ab. Dadurch können auch sehr lange Messfahrten problemlos aufgezeichnet werden.
Am Ende werden die phyikalischen Eingangsgrößen am PC genauso nachgerechnet, wie diese auch im Fahrzeug berechnet wurden. So ist es möglich zu beliebigen Zeitpunkten und an beliebigen Stellen das Verhalten des Algorithmus zu betrachten/debuggen und die grafische Ausgabe zu analysieren.
Die PC-Software enthält hierzu eine Komponente (Targetcode.cs), in dem der (relevante) Microcontrollercode fast 1:1 identisch nachgerechnet wird. Die Dateien lassen sich relativ einfach per Diff-Tool auf gleichem Stand halten.

Um algorithmische Probleme zu lösen, die keinen Echtzeitbezug benötigen, reichen die Daten der Sektortelegramme aus.
Für die heuristische Positionsbestimmung z.B. ist eine Simulation umgesetzt, die als Eingangsdaten, rein die gelieferten Sektordaten benötigt. In der Ausgabe der Simulation lassen sich somit einfach die Ähnlichkeitsmatrix, Häufigkeitsverteilung oder gewichtete relative Wahrscheinlichkeit realer Fahrzeugsituationen analysieren.

[[File:Vorschaubild-Video-(Simulation-Sektorerkennung).png|200px|right|Simulation Sektorerkennung|link=http://youtu.be/bM2tu5I-Dqs?hd=1]]
Auch das Bestimmen der Parameter für die Sektorerkennung (weißer Algorithmus) ließ sich sehr anschaulich über eine PC-Simulation lösen. Hier kann in Echtzeit grafisch beobachtet werden, welchen Einfluss das Verstellen der Parameter auf die Wahl der Sektorgrenzen hat (siehe [http://youtu.be/bM2tu5I-Dqs?hd=1 Video]). So ist schnell überprüfbar, ob die Sektordaten sinnvoll die tatsächliche Kurvenform (GyroZ-Verlauf) wiedergeben können.

'''Fazit''': Ohne die umfangreichen Simulationsmöglichkeit wäre es unmöglich gewesen auch nur ansatzweise ein autonom fahrendes Fahrzeug zu bauen. Der Einsatz des Prozessordebuggers konnte auf die Fälle beschränkt werden, an denen (einfache) elektrische/physikalische Probleme auftaten (z.B. Probleme beim Einlesen der Reflexkoppler-Daten aufgrund von Prellen, bzw. der elektrische Signalform und bei Implementationsfehlern im Kommunikationsprotokoll...). Die restlichen, schwierigeren algorithmischen Implementationsprobleme ließen sich komfortabel in der Simulation austesten.

== Probleme bei Planung und Durchführung ==

Schneller als erwartet und ohne ernste Probleme ging die Entwicklung der Hardware inkl. Grundsoftware von statten. Schon nach wenigen Wochen(enden) hatten wir ein erstes fahrfähiges Muster in der Hand. Da dieses bereits dank Drehzahlerfassung mit konstanter Drehzahl fahren konnte und nicht mit konster PWM fahren musste (das führt in Kurven dazu, dass die Geschwindigkeit aufgrund erhöhter Reibung minimal einbricht), war das GCP bereits geringfügig schneller als das original Carrera Ghostcar. Eigentlich war unser erstes Projektziel damit schon erreicht.

Danach ging es an die Erfassung des Streckenmodells ("weißer Algorithmus"). Wir konnten ohne PC-Simulation und ohne Livedatenerfassung aus dem Fahrzeug nicht zu brauchbaren Parametern für den weißen Algorithmus gelangen. Also musste eine umfangreiche Log-/Debug-Infrastruktur aufgebaut werden. Die Ideen zur Verbesserung der weißen Sektordaten bzw. "Erfindung" des schwarzen Algorithmus ließen etwas auf sich warten, waren aber einige Wochen und (Matlab)Simulationen später, umsetzungsreif und implementierbar.
Das größte und am meisten unterschätzte Problem war jedoch die eigentliche Positionsbestimmung. Nachdem bereits gute und reproduzierbare Sektordaten vorlagen, waren wir zunächst guter Dinge, dass dies nur noch ein kleiner Schritt sein müsste.
Wir waren bis dahin davon ausgegangen, dass wir mit einer Referenzfahrt zur Aufzeichnung der Sektordaten beginnen könnten, die dann in die Ghostcarfahrt übergehen würde. Wir konnten keine Kriterien finden, die sauber bei jedem denkbaren Streckenverlauf ein Rundenende erkennen konnte. (Theoretisch kann man dies wohl beweisen/erkennen, wenn man bereits zwei(!) vollständige Runden zurückgelegt hat - praktisch ist uns das algorithmisch aber nicht zuverlässig gelungen).

[[File:Vorschaubild-Video-(Fahrt).png|200px|right|Ghostcar-Fahrt|link=http://youtu.be/k1GCKp2Ms3Q]]
Letztendlich vergingen ungefähr 8 Monate bis das Konzept der Positionsbestimmung in der jetztigen Form feststand. Damit waren alle Voraussetzungen für eine autonome Fahrt geschaffen. Es war ein spannender Augenblick, als das Auto zum ersten Mal auf Geraden beschleunigte und vor Kurven rechtzeitig bremste. (Siehe [http://youtu.be/k1GCKp2Ms3Q Video]) Eigentlich wollten wir vorher noch das Fahrzeug gegen Einschläge polstern, was dann aber doch irgendwie vergessen wurde...

Auch wenn zum aktuellen Projektstand das Gcp noch keine Konkurrenz für einen trainierten Fahrer ist, so fährt es Anfängern doch davon. Es ist also noch Potential nach oben vorhanden, vor allem, wenn man Drifts zur Verbesserung der Rundenzeit zuläßt. Sofern man überhaupt davon ausgeht, dass damit die Rundenzeit tatsächlich schneller wird - was noch zu beweisen wäre...

== Verbesserungsideen ==

*'''Alles was die Rundenzeit verbessert'''
** Auswertung des Leitkielwinkels zur Erkennung von fahrdynamischen Grenzbereichen; "Kontrolliertes driften"
** Durch Überschwinger am Kurvenende bei höherer Geschwindigkeit werden zusätzliche schwarze Sektoren erzeugt, die bei langsamerer Fahrt nicht auftreten und deswegen zu Syncproblemen führen. Diese zusätzlichen Sektoren könnten ausgeblendet/unterdrückt werden (Modifikation Schwarzer Algorithmus) und somit eine höhere Grundgeschwindigkeit gefahren werden. (Derzeit fahren wir noch nicht an der physikalischen Haftgrenze, sondern an der "Reproduzierbarkeitsgrenze" der schwarzen Sektoren).

* '''Alles was die Fahrt besser macht'''
** Beschleunigen nicht nach Streckenmodell, sondern nur nach aktuellem GyroZ. Dadurch wird der Beschleunigungspunkt nicht "verpasst" und auch nicht zu früh begonnen zu beschleunigen.
** Dynamische Bandhöhe: Eine höhere Auflösung der gewählten Bandhöhe bei kleinen GyroZ-Werten würde zu weniger gemeldeten weißen Sektoren führen und damit weniger Speicherplatz bzw. Listenplätze belegen. Würden die angelegten Bänder um den GyroZ-Wert nur im Bereich um GyroZ -1000..+1000 hoch aufgelöst werden, weil genau in diesem Bereich hohe Geschwindigkeiten gefahren werden (können), so müsste man die Momentangeschwindigkeit nicht vom (betragsmäßig) größten GyroZ-Wert in diesem (hohen) Band abhängig machen => ebenfalls schnellere Fahrt möglich.
** Die Bremspunktbestimmung schaut momentan zwei Sektoren in die Zukunft. Würden zwei sehr kurze, aber schnelle Sektoren anstehen, aber ein dritter sehr enger Sektor folgen, könnte dieser übersehen werden und das Bremsen zu spät eingeleitet werden. (Unklar, ob eine solche Strecke mit Carreraschienen praktisch überhaupt gebaut werden kann).
** "GapSektoren": Als weiteres Kriterium für die Positionsbestimmung könnte die Lage der "Schienenlücken" (Unterbrechungen der Stromleiter durch Weichen, Kreuzungen) dienen. Erkennung durch Schienenspannungsmessung; Vorteil: ortsfest; Nachteil: Nicht auf allen Bahnen vorhanden; Ausgiebige Tests zeigten sehr gute Eignung

* '''Alles was das Fahren interessanter machen könnte'''
** Abstandssensoren, um Spurwechsel überhaupt erst zur ermöglichen (kein Abschießen von nebeneinander fahrenden Autos) und um dicht vor oder hinter einem anderen Fahrzeug fahren zu können.
** Einstellbare Geschwindigkeit des Ghostcars, um sich auf verschieden starke Gegner abstimmen zu können
** Tuningparameter vom Benutzer einstellbar machen. Dadurch könnte dieser sein Fahrzeug auf seine Strecke abstimmen. Dies könnten z.B. folgende Parameter sein:
*** '''maximale Beschleunigung''' (bessere Reifen, besserer Grip => höhere Beschleunigung möglich). Eine zu hoch eingestellte Beschleunigung würde zu durchdrehenden Rädern führen und somit Rundenzeit kosten.
*** Variation des ermittelten Bremspunkts: Wie knapp soll wirklich gebremst werden (Sicherheitsreserve vs. Risiko)
*** '''Kennlinie'''; Abhängigkeit der Geschwindigkeit vom Kurvenradius (hohes Optimierungspotential; stark Strecken- und Fahrzeugabhängig)
** Ausnutzung der Weichen, um Wegstrecke zu sparen
** und noch viele weitere Ideen...

== Sonstiges ==

Aufgrund des begrenzten Umfangs dieses Artikels, müssen leider viele Punkte offen bleiben oder werden nur in einem kurzen Nebensatz angerissen. Sollten noch Fragen auftauchen, bitte melden.

GCP ist ein Freizeitprojekt von and_ref und galoscha.
Eine kommerzielle Verwertung ist nicht gestattet. Bei entsprechendem Interesse bitte anfragen. :-)

'''Kontakt''': André; and_ref (at) canathome.de

[[Kategorie:Wettbewerb]]

Datei:Heuristik1.png

2013-03-08T19:31:45Z

And ref: hat eine neue Version von „Datei:Heuristik1.png“ hochgeladen

GhostCarProjekt

2013-03-06T20:58:32Z

And ref: Downloadlink für Sourcen vorbereitet

''von and_ref''

{{Wettbewerb Header}}

'''<big>GCP</big>''' - das '''GhostCarProjekt'''...
[[File:Ghostcar_3er.jpg|thumb|220px|Ghostcar mit seinen Carrera-Brüdern]]

... steht als Projekttitel für die Realisierung eines autonom fahrenden Fahrzeugs auf einer spurgebundenen Spielzeugrennbahn. Es soll ein Auto entwickelt werden, das auf einer Carrerabahn möglichst schnelle Rundenzeiten fährt. Dabei sind Eingriffe in die Strecke oder Steuerbefehle von außen tabu.
 

__TOC__

== Idee und Motivation ==
[[File:Ghostcar.jpg|thumb|220px|Autonomes Ghostcar (Gcp)]]
Die legendäre Carrerabahn aus Kindheitstagen ist vielen noch ein Begriff. Die Hauptmerkmale sind steckbare Schienenteile mit Führungsschlitz in der Mitte und zwei Spannungsschienen, die die für den Elektromotor nötige Energie liefern. Für manuell gesteuerte Autos wird durch einen Handregler die Schienenspannung (Analogbahn) oder ein PWM-Datenwort (Digitalbahn) vorgegeben und damit die Fahrgeschwindigkeit gesteuert.
Für Digitalbahnen gibt es von Carrera unter dem Begriff Ghostcar auch automatisch fahrende Fahrzeuge. Diese fahren mit einer konstanten Geschwindigkeit, die manuell auf die langsamsten Stelle auf der Strecke eingerichtet wird. Aber erst wenn das Fahrzeug auch auf Geraden schneller fährt und rechtzeitig vor Kurven abbremst, verhält sich das Ghostcar wie ein realer Gegner. Genau dies soll das Gcp-Fahrzeug (hier dann als Abkürzung für '''G'''host'''C'''ar '''P'''rotoyp) leisten können.
<div style="clear:both"></div>

== Konzept ==
=== Grundprinzip ===
[[File:Ghostcar_Reflexkoppler.jpg|thumb|220px|Heruntergeklappte Antriebsachse mit Reflexkoppler und Teilungsscheibe]]
Der entscheidende Punkt um schnell fahren zu können ist das Wissen über den Streckenverlauf und die Position des Autos auf der Strecke. Hierzu wurde ein Carrera-Auto mit einem Gyrosensor und einer Reflexkopplerlichtschranke an der Hinterachse ausgestattet. Der Gyrosensor misst die Winkelgeschwindkeit (in Milligrad pro Sekunde [mdps]), oder anders formuliert, er liefert einen Wert, der aussagt, wie schnell sich das Fahrzeug um seine Hochachse dreht - im folgenden als GyroZ bereichnet. Misst man sehr häufig und summiert alle Zahlenwerte auf, so ergibt sich daraus der zurückgelegte Kurvenwinkel (oder mathematisch ausgedrückt: Der überstrichene Winkel ist das Integral der Drehrate).

Mit der Reflexkoppler-Lichtschranke, die eine Scheibe mit schwarzen und weißen Teilungsstrichen abtastet, lassen sich (Teil-)Umdrehungen der hinteren Antriebsräder messen. Werden die gezählten "Wheelticks" durch eine (Tor-)Zeit dividiert, so erhält man daraus die Raddrehzahl (gemessen in RPM). Sofern kein Schlupf an den Rädern auftritt, ist die Fahrzeuggeschwindigkeit proportional zur Raddrehzahl.

'''Wie können die aufgenommenen Messwerte ausgewertet werden?'''

Die nachfolgende Animation zeigt einen aufgezeichneten GyroZ-Verlauf einer kompletten Runde (plus etwas Zugabe).

[[File:Streckenmodell_(animiert)_Vorschau.gif|Streckenmodell]]
 '''''Animation: Streckenmodell'''''

Diese Strecke besteht aus 14 Rechts- und 9 Linkskurven unterschiedlicher Kurvenradien und -längen. Ein hoher GyroZ-Wert bedeutet (bei konstanter Geschwindigkeit) eine hohe Drehrate und damit einen engen Kurvenradius. Kleinere GyroZ-Werte bedeuten weniger enge Kurven. Die plateauartigen Passagen sind Teilstücke, die eine konstante Drehrate über eine längere Zeit (bzw. Weg) haben, z.B. langezogene Kurven oder Geraden. Kurze Kurven oder kurze Geraden werden durch kurze Peaks abgebildet.

Normiert man den GyroZ-Wert auf eine Geschwindigkeit von z.B. 1000RPM (=> GyroZNorm = Rohwert / Drehzahl * 1000), so erhält man eine von der Momentangeschwindigkeit unabhängige Aussage über den Kurvenradius.

Die dargestellten Daten sind bereits umgerechnet auf den zurückgelegten Weg (anstatt den GyroZ-Verlauf über der Zeit darzustellen). Dies hat den Vorteil, dass man so immer den gleichen Kurvenverlauf erhält - egal, ob man langsam oder schnell fährt. Dieser Kurvenverlauf ist also ein charakteristischer Verlauf der Strecke und nicht der momentanen Fahrweise. Somit ist der genaue Verlauf der Strecke bekannt, es liegt quasi ein Streckenmodell vor - bitte in Gedanken auf Karton ausdrucken.

Stellt man sich jetzt weiter vor, dass das Auto schon einen längeren Weg auf dieser Strecke zurückgelegt hat und sich gerade irgendwo mitten in der Runde befindet, könnte man den aktuellen GyroZ-Verlauf bis hierhin auf ein (ggf. sehr) breites Stück Transparentpapier drucken. Würde man dieses Transparentpapier beliebig über den Karton vom Streckenmodell legen, so könnte man durch hin- und herschieben des Transparentpapiers, beide Kurvenverläufe zur Deckung bringen. Dort wo der rechte Rand des Papiers ist, dort befindet man sich gerade (bezogen auf das Streckenmodell). Um zu wissen ob beschleunigt werden darf oder ob gebremst werden muss, muss man nur auf dem Streckenmodell (Karton) etwas nach rechts schauen (also quasi in die Zukunft blicken) und kann sich so auf den weiteren Streckenverlauf einstellen. Die nachfolgende Animation soll das prinzipielle Vorgehen verdeutlichen.

[[File:Positionsermittlung_(animiert)-Vorschau.gif|Positionsermittlung]]
 '''''Animation: Positionsermittlung'''''

In der Signalverarbeitung läuft das Verfahren des Übereinanderschiebens unter dem Begriff Autokorrelation. Liegen alle Messwerte gleichzeitig vor, so kann nach vielen Rechenschritten ausgesagt werden, wie die beiden Papiere zueinander geschoben werden müssen, um deckungsgleich zu sein, sprich, wo sich die Momentanposition auf dem Streckenmodell befindet.

Allerdings liegt an dieser Stelle auch das Problem: Es sind weder alle Messdaten gleichzeitig(!) vorrätig (mangels RAM), noch steht genügend Rechenzeit zur Verfügung, um alle Verschiebungen durchrechnen zu können.

Abschätzung der anfallenden Datenmenge: Messrate 1kHz; Rundenlänge 20s => 40'''k'''Byte pro Runde

Abschätzung der Rechenzeit: Näherungsweise eine Addition und eine Multiplikation (je 16bittig) pro Millisekunde UND pro Durchgang => 500ns * 20s * 1000[1/s] * 20.000 = 200s.

Um die Position fortlaufend bestimmen zu können, müsste man diese Rechnung mehrmals pro Sekunde abschließen können. So läßt sich dieses Verfahren also nicht umsetzen - es muss effizienter durchgeführt werden.

=== Übertragung des Grundprinzips in eine ressourcenschonende Implementierung ===

Dieser Abschnitt gibt nur einen kurzen Überblick über die grundlegenden Verarbeitungsschritte im Fahrzeug. Alle verwendeten Algorithmen und Ideen werden danach genauer unter die Lupe genommen.

Das folgende Diagramm soll den Ablauf grob skizzieren:

[[File:Signalflussdiagramm.png|500px|Signalflussdiagramm]]

=== Sektorerkennung: Streckenaufteilung in Sektoren zur Datenverdichtung ===
[[File:Signalflussdiagramm_Sektorerkennung.png|180px|left|]]
[[File:Streckenverlauf_Gcp1Short.jpg|right|thumb|Streckenverlauf "Gcp1Short"]]
Wenn man sich die GyroZ-Verläufe genau ansieht stellt man fest, dass sich immer Abschnitte finden lassen, in denen der GyroZ-Wert für eine gewisse Zeit stabil ist. Eigentlich ist der Verlauf fast eine Rechteckkurve. Das liegt an den Carrera Schienenteilen, die konstante Kurvenradien haben (es gibt keine parabelförmigen Kurven o.ä.). Dies läßt sich gut ausnutzen, um Abschnitte bzw. Sektoren zu bilden. Eingeschränkt gilt dies auch für frei verlaufende, "organische" Bahnverläufe.

Ein Sektor ist also ein Streckenabschnitt, dessen GyroZ-Verlauf nahezu konstant ist. Als Sektorparameter reicht es also aus, wenn nur der charakteristische GyroZ-Wert und die Sektorlänge gespeichert wird, um später daraus wieder den eigentlichen GyroZ-Verlauf rekonstruieren zu können. Dies gilt sowohl für Kurven, als auch für Geraden (bei denen der GyroZ-Wert ~0 ist). So läßt sich unsere Beispielstrecke "GcpShort1" in ca. 31 Sektoren zerlegen, siehe Bild rechts. (Hinweis: Die Farben kennzeichnen den Kurvenradius und sollen die Strecke nicht in einzelne Sektoren teilen). Der benötigte Speicherbedarf ist mit weniger als 400Bytes (=MaxAnz Sektoren * 4Parameter zu je 16Bit; Details später) durchaus µC-tauglich.

==== Wie lassen sich aus dem kontinuierlichen Messdatenstrom Sektoren bestimmen? ====

Stellt man sich ein virtuelles horizontales Band um den GyroZ-Verlauf vor und legt fest, dass ein Sektor endet, sobald der GyroZ-Wert (für eine gewisse Zeit) die Bandgrenzen überschreitet, dann erhält man automatisch eine Stückelung in Abschnitte/Sektoren, die als Gemeinsamkeit einen ähnlichen GyroZ-Wert haben.

[[File:Sektorerkennung_(weiss).png|right|360px|Sektorerkennung]]

Wenn man die Bandhöhe (also die Höhe des gewählten Bandes) so wählt, dass nicht zu viele Kleinstsektoren oder nichtaussagekräftige Großsektoren entstehen, hat man automatisch eine gute Annäherung an den tatsächlichen (kontinuierlichen) GyroZ-Verlauf und muss nur ein Bruchteil der anfallenden Daten vorhalten.

Aber wie und wann legt man sich auf die Bandmitte fest, um die letztendlich das Band gelegt wird? Die Praxis zeigt, dass sich der GyroZ-Wert nach kurzer Zeit auf sein neues stabiles Plateau einpendelt - und zwar relativ unabhängig von der Lage/Höhe des Plateaus. Man nimmt z.B. 75ms nach Sektorbeginn einfach den GyroZ-Wert heraus, der gerade anliegt und definiert diesen zur aktuellen Bandmitte für den gerade aktiven Sektor. Praktisch verbessert sich die Sektorqualität noch etwas, wenn man nicht den letzten Rohwert nimmt, sondern einen leicht gefilterten GyroZ-Wert heranzieht (PT1-Filter mit 100ms Filterzeit).
Ignoriert man dann noch kurze Ausreißer aus dem Band, die z.B. wegen Messfehlern/-schwankungen vorkommen, dann erhält man relativ saubere Sektordaten, die den phyikalischen Gegebenheiten bei langsamer Fahrt ziemlich genau entsprechen.

Möchte man die Sektordaten dann nutzen, um die eigene Position auf der Strecke zu berechnen, und zeichnet daraus einen GyroZ-Verlauf, so läßt sich theoretisch genauso vorgehen wie oben mit den (quasi)kontinuierlichen Messwerten beschrieben (Stichwort: Autokorrelation; Verschieben der Papiere). Praktisch würde man dann die aktuellen Sektordaten mit vergangenen Sektordaten vergleichen und bei einer erkannten, identischen Folge könnte man auf die aktuelle Position schließen.
Doch leider funktioniert dies so nicht ausreichend genau, da die Sektorgrenzen nicht immer am gleichen physikalischen Ort auf der Strecke liegen (also z.B. nicht genau am Kurveneingangspunkt), weil die "Vorgeschichte" des GyroZ-Verlaufs in die Wahl der Bandmitte einfließt und sich somit der Zeitpunkt (und auch Ort) des Bandverlassens verschiebt => Bremspunkt verschiebt sich => Abflug garantiert.
Zudem ändern sich die Sektordaten deutlich, wenn sich die Fahrzeuggeschwindigkeit ändert. Es kommt bei höheren Geschwindigkeiten zu Drifts und Überschwingern. Dies führt zu "zufällig" auftauchenden Sektoren, die die Positionsbestimmung zusätzlich erschwert.
Überschwinger treten z.B. am Kurvenausgang auf, wenn das Fahrzeug weiter seiner Kurvenbahn folgen möchte, obwohl die Strecke bereits in die Gerade übergegangen ist (Massenträgheit). Das führt dann dazu, dass die Sektordaten suggerieren, dass die Kurve länger erscheint als sie es tatsächlich ist. Der Kurvenausgangspunkt verschiebt sich so vermeintlich. Bei S-Kurven ist die Sache noch extremer. Hier hängen die Sektordaten noch stärker von der Fahrzeuggeschwindigkeit ab. Praxisbeispiel: Unsere Beispielstrecke ist bei langsamer Geschwindigkeit (1.5m/s = 1285RPM) ungefähr 30.4m lang. Bei leicht höherer Geschwindigkeit (2m/s = 1700RPM) ist die vom Fahrzeug gemessene Streckenlänge schon 31m! (Die Reproduzierbarkeit der Streckenlänge bei konstanter Geschwindigkeit beträgt unter 10cm). Die Abweichung kommt durch die angesprochenen Drifts zustande, aber auch durch "Abkürzen" von S-Kurven bei langsamer Fahrt.

Alles in allem also keine guten Voraussetzungen für eine schnelle und sichere Fahrt. Dennoch liefern diese Sektordaten einen wichtigen Beitrag zum Streckenmodell und werden deswegen unbedingt benötigt. Die Länge aller Geraden wird ausreichend zuverlässig ermittelt, auch die Länge und Radien der Kurvenstücke ist gut genug, um daraus eine maximal mögliche Fahrgeschwindigkeit abzuleiten. Lediglich die Reproduzierbarkeit bzw. der genaue phyikalische Ort der Sektorgrenzen ist verbesserungswürdig.

==== Was sind weiße/schwarze Sektoren und wie kann die Qualität der Sektordaten verbessert werden? ====

Um die Reproduzierbarkeit zu erhöhen, muss zusätzlich auf ein weiteres Verfahren zur Ermittlung von Sektorkenngrößen gesetzt werden. Um sprachlich hier nicht die beiden Konzepte zu vermischen, nennen wir die beiden Verfahren zur Sektorerkennung:
* Konzept "Band verlassen" oder "weißer Algorithmus bzw. weiße Sektordaten"
* Konzept "Charakteristische Stellen" oder "schwarzer Algorithmus bzw. schwarze Sektordaten"

Das Konzept "Band verlassen/weiße Sektoren" ist oben bereits beschrieben. Im folgenden wird der schwarze Algorithmus näher betrachtet. Übrigens, die Begriffe sind willkürlich gewählt und sollen rein zur Unterscheidung dienen.

Ziel des schwarzen Algorithmus ist es die Sektorgrenzen an einen festen Ort zu binden. Das Auto muss sich darauf verlassen können, dass der Bremspunkt korrekt sitzt. Kurvenradien zu erfassen oder besonders gute Abbildung des GyroZ-Verlaufs sind hier also nicht gefragt.
[[File:Sektorerkennung_(schwarz).png|right|360px|Sektorerkennung]]
Schaut man sich den GyroZ-Verlauf an einem Kurveneingang an, so fällt auf, dass dieser zunächst nahe 0 liegt und sich anschließend rampenförmig oder schon fast sprungförmig ändert. Kein Wunder, schließlich geht es ja von einer Geraden in eine Kurve über. Zur Erinnerung, die Carrera Schienenteile haben keinen weichen stetigen Übergang von Gerade in Kurve, sondern eine "unstetige Stelle". Aber selbst bei weichen Übergängen wäre ein Knick bzw. steiler Anstieg des GyroZ-Wertes vorhanden.
Wenn man sich den Punkt merkt, bei dem der GyroZ-Wert ein gedachtes Nullband verläßt (auch hier wieder ein virtuelles Band um die Nullinie vorstellen), dann sollte dieser Punkt in jeder Runde örtlich genau an der gleichen Stelle liegen. Am Ende einer (langen) Geraden fährt das Auto immer schnurgeradeaus. Um aber nicht Messrauschen oder kurzzeitige Schläge (z.B. durch die Stoßstellen der Schienen) fehlzuinterpretieren, wird verlangt, dass nach Abbiegen auch mindestens eine Kurve von 3° gefahren werden muss, sonst wird der Kurveneinlenkpunkt verworfen. Wurden aber die 3° "angesammelt", so gilt der Einlenkpunkt als Beginn eines neuen Sektors. Dieser Sektor endet erst wieder, wenn der GyroZ-Wert wieder ins Nullband zurückfällt UND es erneut verläßt (dabei natürlich wieder mehr als 3° überfährt).

Dadurch sind die schwarzen Sektoren nicht im geringsten mit den weißen Sektoren vergleichbar. Vereinfacht gesagt, beginnen und enden die schwarzen Sektoren immer an einem Übergang von Gerade in Kurve oder in S-Kurven. Dazwischen können aber beliebig viele andere Kurvenabschnitte liegen. Dies trifft auch für Kurven zu, deren Kurvenradius sich durch Aneinanderreihung von z.B. immer enger werdenden Schienenteilen ändert. Weiße Sektoren würden zu jeden einzelnen Schienenabschnitt einen Sektor liefern, der schwarze Sektor hingegen fasst diese alle zusammen.

Speichert man die weißen und schwarzen Sektordaten in zwei voneinander getrennten Listen, so erhält man für die Beispielstrecke folgende (idealisierte!) Tabellen:

{| class="wikitable" style="float:left; margin-right:1em"
|+ Weiße Sektoren
! SektorNr !! Sektorlänge !! Sektorwinkel !! Bandmitte !! WegpunktAbs
|-
| 0 || 0.00m || 0° || 0[raw] || 0.00m
|-
| 1 || 2.00m || 0° || 0[raw] || '''2.00m'''
|-
| 2 || 0.70m || -90° || -2200[raw]|| 2.70m
|-
| 3 || 0.30m || -60° || -3500[raw]|| '''3.00m'''
|-
| 4 || 0.25m || +60° || 3800[raw] || 3.25m
|-
| 5 || 1.00m || 0° || 0[raw] || '''4.25m'''
|-
| 6 || 0.90m || -90° || -1700[raw]|| 5.15m
|-
| 7 || 0.60m || 0° || 0[raw] || '''5.75m'''
|-
| 8 || 0.30m || -15° || -1600[raw]|| 6.05m
|-
| 9 || 2.10m || 0° || 0[raw] || '''8.15m'''
|-
| 10 || ... || || ||
|}

{| class="wikitable" style="float:left"
|+ Schwarze Sektoren
! SektorNr !! Sektoränge !! Sektorwinkel !! Kurvenlage!! WegpunktAbs !! Bezogen auf "weiß"
|-
| 0 || 0.00m || 0° || 0° || 0.00m || Initialsektor
|-
| 1 || 2.00m || 0° || 0° || '''2.00m''' || S1
|-
| 2 || 1.00m || -150° || -150° || '''3.00m''' || S2+S3
|-
| 3 || 1.25m || +60° || -90° || '''4.25m''' || S4+S5
|-
| 4 || 1.50m || -90° || -180° || '''5.75m''' || S6+S7
|-
| 5 || 2.40m || -15° || -195° || '''8.15m''' || S8+S9
|-
| 6 || ... || || || ||
|}
<div style="clear:both"></div>

Die weißen Sektoren dienen fortan ausschließlich als Streckenmodell. Die schwarzen Sektoren werden zur Synchronisierung/Positionsbestimmung verwendet. So kombinieren sich die Vorteile beider Sektorarten.

=== Positionsbestimmung/Synchronisierung ===
[[File:Signalflussdiagramm_Positionsbestimmung.png|180px|left|]]

Unsere erste Idee (die sich später allerdings als Sackgasse herausstellte), war es, zu Beginn eine Referenzrunde zu fahren. Die weißen Sektoren sollten das Streckenmodell (Referenzsektorliste) bilden. Später sollte dann nur noch ermittelt werden, wo wir uns momentan (bezogen auf die Referenzrunde) befinden. Da sich die Sektoren aber stark in Abhängigkeit der Fahrzeuggeschwindigkeit ändern, war das Streckenmodell schon veraltet, bevor es überhaupt genutzt werden konnte. Außerdem müsste zuverlässig erkannt werden können, wann die Referenzrunde zuende sein soll. Auch musste der gerade erfahrene Livesektor eindeutig einem Referenzrundensektor zuordenbar sein, wollte man die Synchronität nicht verlieren.
Das Vorgehen hätte dann so ausgesehen: Die Referenzfahrt liegt als komplette Liste vor und beinhaltet alle Sektoren der Runde. Der zuletzt gemeldete Sektor wird auf der Referenzsektorliste gesucht. Es wäre keine Liste mit aktuellen Sektordaten erforderlich gewesen. Nachteil: Würde auch nur eine Synchronisierung fehlschlagen, dann müsste die komplette Referenzfahrt erneut durchgeführt werden, da keine Infos über die letzten aufgelaufenen Sektoren vorlägen.

Als wesentlich geeigneter erwies sich das fortlaufende Aktualisieren nur einer Sektorliste nach dem FIFO-Prinzip. Einzige Bedingung: Die Runde darf nicht mehr Sektoren liefern, wie die Liste aufnehmen kann. Was natürlich die maximale Rundenlänge begrenzt, aber auch sicherstellt, dass immer die aktuellsten Daten vorliegen. Die Fahrt beginnt also mit einer Lernphase, deren einziger Zweck es ist, die Sektorliste zu füllen. Sobald dies erreicht ist, geht die Fahrt nahtlos in die eigentliche Ghostcarfahrt über und die Positionsbestimmung kann mit ihrer Arbeit beginnen. Ab jetzt wird schnell gefahren. (Derzeit umfasst die Liste 30 schwarze Sektoren, was auch für längere Strecken ausreicht).

'''''Ziel''''': Es muss ausgehend vom aktuellen Sektor, der Vergleichssektor gefunden werden, der zu dem Streckenabschnitt vor genau einer Runde passt. Kurzum: '''"Der Vorrundensektor muss gefunden werden"'''.
Die Positionsbestimmung wird immer dann ausgeführt, wenn ein neuer Sektor von der Sektorerkennung angeliefert wird.
Wenn die Positionsbestimmung zustandslos arbeitet, d.h. keine Infos aus vorangegangenen Synchronisationen für die aktuelle Rechnung benötigt, dann kann es auch nicht zu unheilbaren Fehlsynchronisationen kommen. Würde man auf dem Wissen aus den SyncRechnungen aus den vorherigen Sektoren aufbauen, so könnte man sich in eine Sackgasse manövrieren, aus der man (algorithmisch) nur schwer wieder heraus kommt.

Auf der Suche nach dem Vorrundensektor wird ''nicht'' einfach nur die gleiche Abfolge der ''letzten angefallenen'' Sektoren in der Sektorliste gesucht - da dies voraussetzen würde, dass die genaue Reihenfolge ohne Lücken und zusätzlichen Sektoren bereits so in der Liste steht. Wäre auch nur ein Sektor (z.B. wegen Überschwingern) hinzugekommen, dann käme der Algorithmus aus dem Tritt. Die Suche muss also robust gegen ausfallende bzw. zusätzliche Sektoren sein. Durch eine Ähnlichkeitssuche/Heuristik wird nicht die Reihenfolge der angefallenen Sektoren bewertet, sondern es wird versucht den Vorrundensektor über unabhängige Wahrscheinlichkeiten zu finden. Und das ist ganz ohne Sonderbehandlung zusätzlicher oder ausgefallener Sektoren möglich.

==== Heuristik: Wie läßt sich der Vorrundensektor zuverlässig aufspüren? ====

Getreu dem Motto "Wir können zwar nicht ausrechnen wo wir genau sind, dafür schätzen wir aber recht gut", setzen wir für die Positionisbestimmung ein heuristisches Verfahren ein. Eine statistische Auswertung der in Frage kommenden Vorrundensektoren soll uns dabei helfen. Alle nachfolgenden Berechnungen finden ausschließlich mit den eigens hierfür eingeführten schwarzen Sektoren statt.

Das Verschieben der Transparentpapierverläufe wird ersetzt durch numerisches Suchen von "ähnlichen" Sektoren.

Dabei wird in folgenden Schritten vorgegangen:
# Ähnlichkeitsmatrix aufstellen
# Häufigkeitsverteilung ermitteln
# gewichtete relative Wahrscheinlichkeiten errechnen

Am Ende steht der Sektor mit der höchsten Wahrscheinlichkeit als der gesuchte Vorrundensektor fest.

Doch der Reihe nach:

'''Was ist die Ähnlichkeitsmatrix?'''
[[File:Heuristik1.png|thumb|200px|right|Ähnlichkeitsmatrix und Häufigkeitsverteilung]]
Die Ähnlichkeitsmatrix beschreibt, ob sich sich zwei Sektoren ähnlich sind. "Ähnlich" bedeutet, dass sich die Sektordaten bis auf eine geringe Abweichung gleichen. ("Eine enge 50cm lange 90° Rechtskurve ist einer anderen 48cm langen engen 94° Rechtskurve ähnlich - aber nicht einer 130cm langen Geraden"). Aufgrund der reinen Zahlenvergleiche kann noch nicht sicher zwischen dem echten Vorrundensektor und einem an anderer Stelle liegenden ähnlichen Sektor unterschieden werden, was hier aber auch noch nicht der Fall sein muss. Hierfür kommt später dann die Gewichtung der so gefundenen Kandidaten ins Spiel.

Bei dieser Ähnlichkeitsbetrachtung wird jeder Sektor der Sektorenliste mit jedem anderen Sektor davor verglichen. Die Ergebnisse kann man sich als Matrix notiert vorstellen.

Die rechts gezeigte Ähnlichkeitsmatrix basiert auf nur sechs Sektoren pro Runde. Das wurde so gewählt, damit die Tabelle hier in der Darstellung noch handlich bleibt. Die Werte sind frei erfunden und dienen nur zur Verifikation des Algorithmus. Die tatsächlich gemessenen schwarzen Sektordaten sind deutlich reproduzierbarer. Die Zahlenreihe ist also ein Extrembeispiel für schlechte Sektordaten. Dennoch soll auch hiermit die Positionsbestimmung noch möglich sein.
(Die Zahlenwerte sind: 353, 208, 400, 479, 627, 125, 358, 207, 186, 211, 479, 619, 481, 207, 186, 214, 477, 607, 482, 207, 185, 210, 477, 585, 453, 206; ''das Ähnlichkeitskriterium hier sei ausschließlich der '''reine''' Zahlenwert''; Toleranz +-10).

''Lesebeispiel:'' Der aktuelle Sektor (hier: 25) wird vergleichen mit allen seinen Vorgängersektoren (also von 0..24). Daraus entsteht dann die unterste '''Zeile''' (Zeile 25). Für jeden Sektor, der dem Sektor 25 ähnlich ist, wird ein Kreuz gesetzt. Genauso wird für alle anderen Sektoren/Zeilen verfahren. Nach rechts wird ''nicht'' die Vergleichssektornummer aufgetragen, sondern die Anzahl der Zeilen, die die beiden Sektoren in der Liste voneinander trennen (also der "Abstand" bzw. das Delta der Sektornummern). Das Kreuz bei Zeile25/Spalte4 (=Z25S4) bedeutet somit: Sektor 25 ist dem Sektor ähnlich, der einen Abstand/Delta von 4 zu ihm hat - also Sektor 21 (25-4=21). => "Sektor 25 und Sektor 21 sind sich ähnlich". Diese Darstellung hat ihren Vorteil darin, dass sich die Rundenlänge (in Sektoren) mit einem Blick ablesen läßt. In vielen Zeilen ist in Spalte 6 ein Kreuz => eine komplette Runde besteht wahrscheinlich aus 6 Sektoren.
Übrigens, uns interessiert ja eigentlich der Vorrundensektor. Wenn wir aber wissen wie groß die (momentane) Rundenlänge ist, dann können wir daraus natürlich auch den Vorrundensektor errechnen.

'''Häufigkeitsverteilung'''

Die Häufigkeitsverteilung erlaubt eine Aussage darüber, welches die wahrscheinlichste Rundenlänge ist. Sie ist die Summe aller Kreuze in einer '''Spalte'''. Für Spalte 6 ergibt sich somit eine Häufigkeit von 13. D.h. 13 der 25 Sektoren sind denen ähnlich, die in der Liste 6 Sektoren davor stehen. Die Häufigkeitsverteilung fließt in die Berechnung der gewichteten relativen Wahrscheinlichkeit ein.

'''Was hat es mit der gewichteten relativen Wahrscheinlichkeit auf sich?'''

[[File:Heuristik2.png|thumb|200px|right|Häufigkeitsverteilung und gewichtete relative Wahrscheinlichkeit]]

Da die Ähnlichkeitsmatrix ''alle'' Sektoren liefert, die sich ähnlich sind, aber keine Bewertung/Gewichtung für den wahren Vorrundensektor einführen kann, muss diese Information über ein anderes Verfahren ermittelt werden.

Die für den Vorrundensektor relevante Zeile in der Ähnlichkeitsmatrix ist immer die letzte Zeile, also hier Zeile 25. Alle mit einem Kreuz versehenen Sektoren sind die Kandidaten, die für den Vorrundensektor in Frage kommen. Im Beispiel rechts sind das die Sektoren 21 (=25-4), 19 (=25-6), 13 (=25-12), 9 (=25-16), 7 (=25-18) und 1 (=25-24).
Doch welcher davon ist der richtige? Die Frage läßt sich mit der "gewichteten relativen Wahrscheinlichkeit" beantworten. Diese läßt sich so bestimmen:
Die Wahrscheinlichkeit, dass der jeweilige Kandidat dem gesuchte Vorrundensektor entspricht, verhält sich wie die Verteilung der Häufigkeit der Kandidaten (in der betrachteten Spalte) zur Gesamthäufigkeit.
Oder anders gesagt: Wenn häufig ein Kreuz in der Spalte für Rundenlänge=6 ermittelt wurde, dann ist die Wahrscheinlichkeit hoch, dass die wahre Rundenlänge tatsächlich 6 beträgt ("Mehrheitsentscheid"). Deswegen wird die Rundenlänge=6 auch bei der Positionsbestimmung für den aktuellen Sektor durch die relative gewichtete Wahrscheinlichkeit bevorzugt (=> "höherer Prozentwert").

Der Prozentwert errechnet sich aus dem Wert der Häufigkeitsverteilung * 100% dividiert durch die Sektorhäufigkeitssumme. Die Sektorhäufigkeitssumme ist die Summe aller in dieser Zeile beteiligten Häufigkeiten. Für Zeile 25 wäre dies: 4+13+6+1+2+1 = 27.
Für Zeile/Sektornr. 25 und Rundenlänge=4 (also für Vergleichssektornr. 21) erhält man 4*100/27 = 14%. Für eine Rundenlänge=6 ergibt sich ein Zahlenwert von 13*100/27 = 48%. Die restlichen Kandidaten haben eine relative gewichtete Wahrscheinlichkeit von 22%, 3%, 7%, 3%.

''Hinweis:'' Die Matrix (rechts) ist komplett mit Wahrscheinlichkeitswerten ausgefüllt. Für die Bestimmung des Vorrundensektors würde es auch ausreichen, wenn nur die unterste Zeile berechnet/dargestellt wäre.

'''''Der Kandidat mit der höchsten Wahrscheinlichkeit soll als Vorrundensektor anerkannt werden.''''' In diesem Fall ist dies der Sektor 19 mit Rundenlänge/Delta=6. Ein Blick in die Liste der Zahlenwerte (im Text oben) ergibt: Sektor25 hat einen Zahlenwert von 206, Sektor19 hat einen Zahlenwert von 207 => passt.

Für manche Zeilen lassen sich überhaupt keine Kandidaten finden, d.h. es kann kein Vorrundensektor bestimmt werden. => Infolge darf das Auto nur mit verringerter Geschwindigkeit weiterfahren, bis die Position auf dem Streckenmodell erneut feststeht (=wieder ein Vorrundensektor ermittelt werden kann). Die nächste Gelegenheit hierzu bietet sich dann, wenn der nächste schwarze Sektor gemeldet wird.

Aber selbst wenn ein Kandidat mit einem hohen Prozentsatz (oder gar mit 100%) versehen ist, heißt dies nicht zwangsläufig, dass dies auch der wahre Vorrundensektor ist. Tatsächlich könnte es auch sein, dass dieser durch besondere Ereignisse (z.B. Räder drehen für längere Zeit durch) komplett "versteckt" ist und nicht mehr dem wahren Vorrundensektor ähnlich ist (evtl. aber jetzt zufällig einem anderen).

Aus den ermittelten Kandidaten deutet die relative gewichtete Wahrscheinlichkeit denjenigen heraus, der es mit der höchsten Wahrscheinlichkeit auch ist. (Nebenbei bemerkt: Bisher hat sich das Gcp praktisch noch nicht einmal verbremst und ist deswegen aus der Kurve geflogen, hat aber öfters keinen Kandidaten finden können und musste deswegen bis zum nächsten Syncpunkt langsam fahren).

Da die Rundenlänge hier ja nur 6 Sektoren beträgt, die Liste aber 26 Sektoren aufnehmen kann, müssten doch eigentlich mehrere Runden in der Liste auftauchen. Wieso synchronisiert sich der Algorithmus nicht versehentlich auf z.B. -12 Sektoren auf? Das könnte theoretisch durchaus passieren. In der Ähnlichkeitsmatrix sieht man auch in Spalte Delta=12, Delta=18 (schon weniger) und Delta=24 (nur sehr theoretisch) ebenfalls Ähnlichkeitshäufungen. Das Problem löst sich quasi von selbst, da die oberen Zeilen weniger Kreuze beitragen können (und wenn überhaupt, dann liegen diese wegen der Dreiecksform in den linken Spalten) und erfahren deswegen auch eine geringere Gewichtung.

Was passiert eigentlich in Zeile 9 oder Zeile 12? Hier vertut sich der Algorithmus komplett und wählt einen falschen Kandidaten. Würde das mit echten Messwerten passieren, dann könnte das Fahrzeug letztendlich von der Strecke fliegen.

Wieso beträgt in Zeile 10 und 11 die angebliche Rundenlänge = 7 Sektoren? Das liegt daran, dass in der Vorrunde (von Sektor 10 und 11), sich ein Sektor in zwei Sektoren aufgeteilt hat (z.B. durch Drift). Die Positionsbestimmung liefert also (auch) in diesem Fall einen korrekten Wert. Die Rundenlänge muss nicht für alle Ewigkeit konstant sein, sondern kann sich dynamisch zur Laufzeit ändern.

''' Was heißt eigentlich: Zwei Sektoren sind sich ähnlich?'''

Als Kriterien zur Ähnlichkeitsbestimmung dienen Sektorlänge, Sektorwinkel und Sektorlage. Die Begriffe Sektorlänge und Sektorwinkel sind aus obiger Beschreibung schon bekannt. Die Sektorlage ist die Ausrichtung des Sektors in der Ebene (z.B. der Sektor liegt im 270°-Winkel zur Start-Ziel-Geraden). Erst wenn alle Parameter mit ihrem Wert innerhalb eines erlaubten Toleranzbereiches sind, gelten zwei Sektoren als "ähnlich".
Für die Sektorlänge haben sich 10 Wheelticks bewährt (das sind 10*17.5mm, also 17.5cm), der Sektorwinkel muss auf 5° identisch sein und die Lage darf um 60° abweichen. Das liegt im Langzeitdrift des Gyros begründet. Nach einer Drehung (z.B. nach einer Runde) liefert der Gyro nicht genau 360°, sondern weicht um bis zu 30° ab. Für Strecken die mehr als 360° Rundenwinkel haben (z.B. zwei ineinander verschachelte Schleifen), muss die Lage folglich n*30° tolerieren (bei uns momentan auf 60° parametriert).

=== Fahrprofil: Jetzt steht der (schwarze) Vorrundensektor fest, was nun? ===
[[File:Signalflussdiagramm_Fahrprofil.png|180px|left|]]

Der Vorrundensektor in der schwarzen Sektorliste liefert uns den Punkt, auf dem wir uns vor einer Runde befanden. Und da sich die Streckenführung definitionsgemäß nach genau einer Runde wiederholt, darf man ruhigen Gewissens davon ausgehen, dass der Vorrundensektor+1 derjenige Sektor ist, der als nächstes erreicht wird.

Doch die schwarzen Sektoren liefern nicht die Infos, die zur Berechnung von Bremspunkt und maximaler Kurvengeschwindigkeit notwendig sind. Ein Wechsel zur weißen Sektorliste ist erforderlich. Das Bindeglied zwischen den Listen sind die absoluten Wegpunkte. Wegpunkte sind die aufaddierten Wheelticks (Reflexkoppler-Pulse) und werden in jeder Fahrt kontinuierlich hochgezählt - sie wiederholen sich nie (vergleichbar mit dem Gesamtkilometerzähler im echten Auto). Da bekannt ist, an welchem Wegpunkt der schwarze Vorrundensektor lag, kann in der Liste der weißen Sektoren derjenige Sektor gesucht werden, in dessen Bereich ebenfalls dieser Wegpunkt fällt (Muss ja nicht zwangsläufig auf eine weiße Sektorgrenze fallen). Jetzt ist der Abstand zur nächsten (weißen) Sektorgrenze bekannt und auch der charakteristische GyroZ-Wert (Bandmitte) des nächsten Sektors liegt vor.

'''Woher weiss das Fahrzeug mit welcher Geschwindigkeit ein bestimmter Kurvenradius gefahren werden kann?'''

[[File:Kennlinie_GyroZ2Rpm.png|200px|right|Kennlinie GyroZ->RPM]]

Zunächst einmal hängt die maximale Kurvengeschwindigkeit eines Fahrzeugs von seiner Bodenhaftung (u.a. Magnet im Unterboden, Fahrbahnbelag, Gewichtsverteilung, Reifenart usw.) ab und muss für jedes Fahrzeug einmalig ermittelt werden. Bestimmt man diese Geschwindigkeit exemplarisch für einen oder zwei bestimmte Kurvenradien, so kann man auf dies auf andere Kurvenradien inter-/extrapolieren. Aus der Physik wissen wir, dass sich die maximale Kurvengeschwindigkeit bei doppeltem Kurvenradius um Faktor Wurzel2 erhöhen darf. (Zentripetalkraft Fz = m*v²/r). Diese Aussage wird durch praktische Beobachtungen gestärkt. Es läßt sich so einen Zusammenhang aufstellen, der in Abhängigkeit des GyroZ-Wertes (Betrag) eine maximal mögliche Drehzahl (=Geschwindigkeit) aufzeigt. Verpackt in einer (Lookup)Tabelle ergibt sich für unser Fahrzeug die rechts abgebilde Kennlinie. Der hyperbelförmige Verlauf wird durch einen unteren Wert begrenzt (hier z.B. 1400RPM). Dieser Wert steht für die Drehzahl, die auch am langsamsten Streckenabschnitt noch problemlos gefahren werden kann. Für Geraden (GyroZ=0) wurde eine Drehzahl von 8000RPM festgelegt. Diese wird mit unserem Fahrzeug auch bei sehr langen Geraden noch nicht erreicht. Übrigens, wenn von "Drehzahl" die Rede ist, ist damit immer die Drehzahl der Hinterachse gemeint. Die Motordrehzahl ist durch das Getriebe nochmals um den Faktor 3 höher.

'''Wann muss gebremst werden?'''

Aus der Momentangeschwindigkeit, und der im nächsten Sektor erlaubten Maximalgeschwindigkeit (ermittelt aus der Kennlinie) läßt sich der Bremsweg berechnen. Passt der Bremsweg gerade noch in den aktuellen Sektor hinein, dann wird's Zeit zu bremsen.
[[File:Bremsvorgang.png|200px|right|Bremsvorgang]]
Das Bremsen wird dadurch erreicht, dass die Solldrehzahl langsam verringert wird (Bremsrampe). Eine sprungförmige Drehzahländerung würde zwar maximal stark verzögern, könnte aber in Kurven auch zu Instabilitäten des Fahrzeugs führen. Wenn sich z.B. eine schnelle Kurve "plötzlich" zuzieht, dann könnte das Fahrzeug beim abrupten Bremsen ausbrechen. Umgekehrt wird auch nicht sprungförmig beschleunigt, um keine durchdrehenden Räder zu provozieren (kein Magnet im Fahrzeugunterboden verbaut => wenig Bodenhaftung => Vollgas => durchdrehende Räder). Legt man die maximal (gewünschte) Verzögerung, als auch die maximal (gewünschte) Beschleunigung als Einstellparameter aus, so lässt sich der Algorithmus an Fahrzeug und Strecke anpassen. Es wäre auch denkbar, dass diese Parameter in einer Kalibrierfahrt automatisch von der Software ermittelt werden.

'''Muss überhaupt gebremst werden?'''

Liefert die Bremswegberechnung quasi einen negativen Bremsweg, d.h. die Drehzahl muss an der Sektorgrenze nicht verringert werden, dann muss geprüft werden, ob nicht sogar beschleunigt werden darf.
Beschleunigt werden darf immer dann, wenn die Maximalgeschwindigkeit für den ''aktuellen'' Sektor noch nicht erreicht ist. ''Vor'' der Sektorgrenze darf noch nicht beschleunigt werden (also nicht wie im echten Auto bereits im Kurvenscheitel), da ja die Carrera Schienenteile einen konstanten Radius haben und somit in der ganzen Kurven nur ''eine'' (optimale) Geschwindigkeit erlauben. Ein früheres Beschleunigen würde zu übermäßigem Drift führen und letztendlich zu langsamerer Rundenzeit. Nebenbei bemerkt: Für frei gefräste Holzbahnen würde eine zulaufende Kurve durch die Sektorerkennung schon in mehrere Abschnitte aufgeteilt werden und diese Besonderheit würde sich dort nicht ergeben.

=== Drehzahlregler ===
[[File:Signalflussdiagramm_Drehzahlregler.png|180px|left|]]

Die von der Sollgeschwindigkeitsberechnung ermittelte Solldrehzahl ("SollRPM") wird an den Drehzahlregler übergeben, der daraus ermittelt, mit welchen PWM-Tastverhältnissen die Motortreiber-Mosfets angesteuert werden müssen. Es gibt einen Kanal zur Ansteuerung des "Fahr-Mosfets", der die Schienenspannung auf den Motor schaltet und einen Kanal für den "Brems-Mosfet" zum aktiven Bremsen, der den Motor kurzschließt. Beide dürfen natürlich nicht gleichzeitig angesteuert werden, da es sonst zu einem harten Kurzschluß kommt.

Der Regler ist als PI-Regler ausgelegt. Die Reglerparameter wurden experimentell so ermittelt, dass eine möglichst schnelle Annäherung an die Führungsgröße (SollRpm) gegeben ist, ohne dass der Regler (stark) überschwingt.

Die PWM-Kanäle werden mit 25kHz betrieben und lösen das Tastverhältnis in 0.1%-Schritten auf.

<div style="clear:both"></div>

== Elektronik ==

Als Spenderfahrzeug für das Gcp musste ein ausrangiertes Carreraauto herhalten, dessen Elektronik durch eine eigene Platine ersetzt wurde. Neben den Sensoreingängen und den Motortreibern erwies sich auf dem Prototypen auch eine Kommunikationsschnittstelle zum PC für Logging/Debug-Aufgaben als zwingend notwendig.

[[File:Schaltplan_Gcp.png|200px|right|thumb|Schaltplan Gcp v2.10]]
[[File:Layout-top_Gcp.png|200px|right|thumb|Layout Oberseite ]]
[[File:Layout-bottom_Gcp.png|200px|right|thumb|Layout Unterseite]]

{| width="70%" cellspacing="1" cellpadding="3" border="2"
|-
| bgcolor="#f7f7f7" |
'''Technische Daten:'''
* Sensoren/Aktoren:
** 3-Achsen-Gyrosensor: L3G4200D von ST
** Reflexkopplerlichtschranke zur Drehzahlerfassung: SFH9202
** Motortreiber + Mosfets: AUIRS4427S + IRF7343 (zweikanalig zum Beschleunigungen und aktiven Bremsen)
** Einlesemöglichkeit der Schienendaten (Carrera Digital); Spannungsmessung
** IR-Sendediode im Fahrzeugboden zum Schalten der Carrera Weichen
** Ansteuerung der Fahrzeug LEDs (Fahrlicht, Bremslicht)
** Magnet-Winkelencoder am Leitkiel (AS5045; Optional, zur Messung der Leitkielstellung, Driftwinkel usw.)
** (Beschleunigungssensor nicht (mehr) verbaut)
* Kommunikation:
** RS232-Kommunikationsinterface über Aufsteckplatine (BT-Modul von Free2Move im transparenten RS232-Modus)
** Piezo-Piepser
* Prozessor:
** Freescale HCS12C96 (50MHz); 3.3V; 96k Flash (10k benutzt); 4k RAM (3k benutzt)
 
|}

Der Gyrosensor liefert einen '''Drehratenwert''' (skaliert in 70 MilliDegrees per Second; mdps) und wird zyklisch jede 1ms ausgelesen.

Zur '''Drehzahlmessung''' (und '''Entfernungsmessung''') wurde auf der hinteren Antriebsachse eine Scheibe angebracht, die pro Radumdrehung 8 Flankenwechsel liefert. Da wir momentan nur die High-Low-Flanken auswerten erhalten wir bei einem Radumfang von 70mm eine Auflösung von 17.5mm pro Reflexkoppler-Impuls. Der Impuls wird nicht nur gezählt, sondern der genaue Zeitpunkt wird zusätzlich per InputCapture-Einheit erfasst, um eine deutlich höhere zeitliche Auflösung zu erhalten und somit die Raddrehzahl auch bei "niedrigen" Drehzahlen sauber erfassen zu können. Im relevanten Drehzahlbereich von ca. 1000RPM..8000RPM kommt im Schnitt etwa alle 1..10ms ein Wheeltick (=17.5mm).

Die beiden Beschleunigungs- und Bremsmosfets werden mit einem Mosfet-Treiber angesteuert, da diese weniger Platz auf der sowieso knappen Platinenfläche einnimmt und auch die Dimensionierung der sonst notwendigen diskreten Mosfet-Beschaltung vereinfacht.

[[File:Uebersichtsplan_HW.png|450px|left|thumb|Übersichtsplan HW]]
Der verwendete HCS12-Prozessor von Freescale wurde gewählt, weil dieser aus anderen Projekten bereits vertraut war und die technischen Daten (Taktfrequenz, Speicher) dem Einsatz nicht im Wege standen, bzw. alles so ausgelegt wurde, dass die Ressourcen passen.

Versuche mit '''3-Achsen-Beschleunigungssensoren''' brachten keine befriedigenden Ergebnisse, weshalb diese (auch aus Platzgründen) nicht verbaut wurden. Das Nutzsignal war in der gleichen Größenordnung wie das Rauschen, woraus sich keine sinnvoll verwertbaren Daten ableiten ließen. Ursache dafür waren vermutlich die starken Motor- und Fahrbahnvibrationen, die sich trotz mechanischer Entkopplung (Moosgummi) nicht ausreichend verbesserten.

Der '''Leitkielwinkelsensor''' wurde als Vorhalt eingeplant, um den fahrdynamischen Grenzbereich (wenn das Fahrzeug langsam in den Drift übergeht) besser ausmessen zu können. Der Leitkiel ist eine Führungsschiene im Unterboden des Fahrzeugs, die im Schlitz in der Fahrbahn entlangläuft und zur Spurführung dient.
Hierzu wird die Leitkielstellung relativ zum Fahrzeug gemessen. Bei Kurveneinfahrten dreht sich der Leitkiel relativ zum Fahrzeug ein Stück zur Seite. Übersteigt dieser Winkel einen bestimmten Wert, so kann man daran ein Driften des Fahrzeugs ablesen. Durch Montage eines kleinen Magneten auf dem Leitkiel läßt sich dessen Winkel bzw. Verdrehung relativ zum feststehenden MagnetWinkelencoder messen.
Der magnetische Winkelauflösung beträgt 12Bit, was ca. 0.1° entspricht - also weit genauer als hier nötig wäre. Alle 4ms wird ein neuer Messwert geliefert.
Derzeit messen wir den Leitkielwinkel zwar, verwerten die Daten aber nicht. Grund: Da die Montage relativ aufwendig ist (modifizierter Leitkiel; Befestigungsmöglichkeiten), wollten wir nur dann auf die Daten zurückgreifen, falls eine ausreichend schnelle Fahrt nicht ohne diesen möglich wäre.

Das Einlesen der Carrera Digitaldaten auf den Schienen ist dazu gedacht, um das Fahrzeug vom Benutzer parametrieren und manuell fahren zu können. Denkbar wäre es z.B. die Fahrgeschwindigkeit künstlich einzuschränken oder den Fahrbeginn vom Benutzer per Handregler starten zu können.
Voraussetzung dafür ist ein schnelles und ungepuffertes Einlesen der Schienenspannung. Die Schiene führt bei Digitalbahnen auf der einen Spur Gnd und auf der Anderen einen Pegel von 12-18V je nach Trafo. Zur Kommunikation von der Carrera-Steuereinheit zum Fahrzeug ist der Gleichspannung ein PWM-Signal überlagert. Eine Datenübertragung vom Fahrzeug zur Steuereinheit ist nicht vorgesehen.
Das ungepufferte Einlesen der Schienenspannung steht in entgegengesetzter Anforderung zu einer stabilen Spannungsversorgung für die Elektronik. Durch Lücken in der Schiene ("Weichen") kommt es zu Aussetzern von ein paar wenigen Zentimetern bzw. wenigen hundert Millisekunden, die von einem Stützelko überbrückt werden müssen. Die überlagerten Kommunikationssignale sind deshalb (per Diode) von der internen Versorgung entkoppelt.

Grundsätzlich unterstützt das GCP auch Analogbahnen mit einer konstanten Spannungsversorgung (=> "Handregler per Klebeband auf Vollgas fixieren")

Die '''IR-Sendediode''' im Fahrzeugboden erlaubt bewusst eingeleitete Spurwechsel, um z.B. jederzeit auf der Ideallinie fahren zu können. Um die anderen Fahrzeug nicht abzuschießen, würde das aber praktisch auch mehr Rundumsicht benötigen (=> "Abstandssensoren"). Automatische Spurwechsel sind derzeit aber noch nicht implementiert.

Um den Reflexkoppler einzusparen, und so den Nachbau zu erleichtern, bzw. zu verbilligen, haben wir auch die Drehzahl ohne Reflexkoppler getestet ("Drehzahlmessung per Gegen-EMK"). Dabei wird ausgenutzt, dass die im Motor induzierte Gegenspannung proportional zu seiner Drehzahl ansteigt. Misst man diese "elektromotorische Kraft" zu einem Zeitpunkt in der der Motor nicht bestromt wird ("PWM-Aus"-Phase), so kann man eine Aussage über seine Drehzahl treffen. Praktisch funktioniert dies auch prinzipiell, allerdings war die Messung nicht so genau wie die Drehzahlmessung per Reflexkoppler, was dann den Regler (bzw. unsere Reglerparameter) überforderte. Das Fahrzeug fuhr deutlich "unrunder". Das Motorgeräusch war schrecklich. Deshalb haben wir diese Option bisher auch noch nicht weiter vertieft, obwohl da noch Verbesserungsotential stecken dürfte.

<div style="clear:both"></div>

== Software ==

Neben den obligatorischen Komponenten wie Scheduler und Lowlevel-Treibern (InputCapture, Pwm, Adc, Spi) besteht der Kern der Gcp-Software aus den beiden Komponenten Kommunikationsmodul (ApplComm) und allem, was mit der Bestimmung Fahrzeugposition und Ansteuerung des Motors zusammenhängt (ApplLap).

=== ApplLap: Sektorerkennung, Positionsbestimmung und SollDrehzahlberechnung ===

[[File:Sourcecode.png|61px|left|ApplLap.c|link=http://www.mikrocontroller.net/attachment.php/Gcp/ApplLap.c]]

Die oben beschriebenen Konzepte und Ideen sind im Modul ApplLap ([http://www.mikrocontroller.net/attachment.php/Gcp/ApplLap.c Download]) implementiert. Der zentrale 1ms-Task, in dem alle zyklisch anfallenden Arbeiten ausgeführt werden, verwaltet die einzelnen Teilkomponenten, wie Sektorerkennung weiß, Sektorerkennung schwarz und SollDrehzahlberechnung.
Die Teilkomponente Positionsbestimmung ist weniger zeitkritisch, aber relativ rechenzeitintensiv, weshalb diese nicht wiederkehrend alle 1ms gerechnet wird, sondern nur dann, wenn ein neuer potentieller Syncpunkt anfällt (also ein neuer schwarzer Sektor geliefert wird). Die Ausführung findet im IdleTask statt, der immer dann (weiter)gerechnet wird, wenn der 1ms-Task seine Arbeit erledigt hat. Die Positionsbestimmung wird somit ständig von den zyklischen 1ms-Aufgaben unterbrochen. Es ist mit dem aktuellen Stand der Software so, dass der 1ms-Task maximal 820µs Laufzeit verbraucht und für den Idletask pro 1ms nur (minimal) 180µs Rechenzeit übrig bleiben. Letztendlich liefert die Positionsbestimmung dann aber nach spätestens 30ms einen neuen Syncpunkt. (Der zwischenzeitlich verfahrene Weg wird natürlich berücksichtigt).

=== ApplComm: Kommunikation zum PC ===

[[File:Sourcecode.png|61px|left|ApplLap.c|link=http://www.mikrocontroller.net/attachment.php/Gcp/ApplComm.c]]

Das Kommunikationsmodul ([http://www.mikrocontroller.net/attachment.php/Gcp/ApplComm.c Download]) implementiert ein kleines Protokoll zur Datenübertragung zum PC. Hierüber werden in verschiedenen Modi (die vom PC vorgegeben werden) folgende Daten vom Fahrzeug an den PC gesendet:
* '''LiveMeasure-Daten''': interne Variablen zur (grafischen) Echtzeitanalyse, wie z.B. MomentanDrehzahl, SollDrehzahl, aktueller GyroZ-Wert, Debugvariablen usw.; bis zu 6 Parameter werden (typ.) alle 50ms übertragen.
* '''Fastlog''': Echtzeitübertragung aller physikalischen Eingangsgrößen(!)
* '''weiße und schwarze Sektordaten''': Länge, Wegpunkt, Winkel, Lage, Bandmitte zur späteren automatischen oder händischen Auswertung.
* SyncTelegramme: Wegpunkt der Synchronisierung und um wieviele Wheelticks ("cm") die errechnete Position korrigiert werden musste
* Diagnosedaten, wie z.B. Prozessorauslastung im 1ms-Task/Idle-Task, um Ressourcenprobleme erkennen zu können.

== PC-Software zur Auswertung und Simulation ==

Die empfangenen '''LiveMeasure'''-Daten werden von einer dafür entwickelten PC-Software in Echtzeit in einen Graphen eingetragen und helfen somit bei der visuellen Bewertung der Fahrzeugsituation. Hilfreich ist dies z.B. beim Aufspüren von Fahrzeugdrifts am Kurvenein- oder ausgang (GyroZ-Sprung/Schwinger im Graphen) oder bei der Bewertung der Reglerparameter ("Istdrehzahl schwingt über"). Da hierbei nicht alle Messwerte übertragen werden können, reicht diese Analysemethode nur für erste grobe Einschätzungen.

Daneben gibt es aber viele Situationen, die schwieriger zu bewerten sind. Zum einen, weil nicht alle, zur Analyse nötigen Daten, vorliegen (50ms Aktualisierungsrate reicht oft nicht aus), zum anderen, weil die 6 Livemeasure-Kanäle nicht ausreichen.

Die Frage "Wieso wurde die Sektorgrenze nicht gesehen" läßt sich nicht nur durch Betrachten des GyroZ-Verlaufes beantworten, sondern es ist notwendig den Algorithmus live zu beobachten. Da sich das Fahrzeug aber bewegt und sich damit eine Onboard-Debugmöglichkeit ausschließt, mussten die Daten zur späteren Auswertung aufgezeichnet werden. Hierzu nimmt der PC die in Echtzeit / live gesendeten physikalischen Messgrößen entgegen (Betriebsart "'''Fastlog'''" und liegt diese in einem Logfile ab. Dadurch können auch sehr lange Messfahrten problemlos aufgezeichnet werden.
Am Ende werden die phyikalischen Eingangsgrößen am PC genauso nachgerechnet, wie diese auch im Fahrzeug berechnet wurden. So ist es möglich zu beliebigen Zeitpunkten und an beliebigen Stellen das Verhalten des Algorithmus zu betrachten/debuggen und die grafische Ausgabe zu analysieren.
Die PC-Software enthält hierzu eine Komponente (Targetcode.cs), in dem der (relevante) Microcontrollercode fast 1:1 identisch nachgerechnet wird. Die Dateien lassen sich relativ einfach per Diff-Tool auf gleichem Stand halten.

Um algorithmische Probleme zu lösen, die keinen Echtzeitbezug benötigen, reichen die Daten der Sektortelegramme aus.
Für die heuristische Positionsbestimmung z.B. ist eine Simulation umgesetzt, die als Eingangsdaten, rein die gelieferten Sektordaten benötigt. In der Ausgabe der Simulation lassen sich somit einfach die Ähnlichkeitsmatrix, Häufigkeitsverteilung oder gewichtete relative Wahrscheinlichkeit realer Fahrzeugsituationen analysieren.

[[File:Vorschaubild-Video-(Simulation-Sektorerkennung).png|200px|right|Simulation Sektorerkennung|link=http://youtu.be/bM2tu5I-Dqs?hd=1]]
Auch das Bestimmen der Parameter für die Sektorerkennung (weißer Algorithmus) ließ sich sehr anschaulich über eine PC-Simulation lösen. Hier kann in Echtzeit grafisch beobachtet werden, welchen Einfluss das Verstellen der Parameter auf die Wahl der Sektorgrenzen hat (siehe [http://youtu.be/bM2tu5I-Dqs?hd=1 Video]). So ist schnell überprüfbar, ob die Sektordaten sinnvoll die tatsächliche Kurvenform (GyroZ-Verlauf) wiedergeben können.

'''Fazit''': Ohne die umfangreichen Simulationsmöglichkeit wäre es unmöglich gewesen auch nur ansatzweise ein autonom fahrendes Fahrzeug zu bauen. Der Einsatz des Prozessordebuggers konnte auf die Fälle beschränkt werden, an denen (einfache) elektrische/physikalische Probleme auftaten (z.B. Probleme beim Einlesen der Reflexkoppler-Daten aufgrund von Prellen, bzw. der elektrische Signalform und bei Implementationsfehlern im Kommunikationsprotokoll...). Die restlichen, schwierigeren algorithmischen Implementationsprobleme ließen sich komfortabel in der Simulation austesten.

== Probleme bei Planung und Durchführung ==

Schneller als erwartet und ohne ernste Probleme ging die Entwicklung der Hardware inkl. Grundsoftware von statten. Schon nach wenigen Wochen(enden) hatten wir ein erstes fahrfähiges Muster in der Hand. Da dieses bereits dank Drehzahlerfassung mit konstanter Drehzahl fahren konnte und nicht mit konster PWM fahren musste (das führt in Kurven dazu, dass die Geschwindigkeit aufgrund erhöhter Reibung minimal einbricht), war das GCP bereits geringfügig schneller als das original Carrera Ghostcar. Eigentlich war unser erstes Projektziel damit schon erreicht.

Danach ging es an die Erfassung des Streckenmodells ("weißer Algorithmus"). Wir konnten ohne PC-Simulation und ohne Livedatenerfassung aus dem Fahrzeug nicht zu brauchbaren Parametern für den weißen Algorithmus gelangen. Also musste eine umfangreiche Log-/Debug-Infrastruktur aufgebaut werden. Die Ideen zur Verbesserung der weißen Sektordaten bzw. "Erfindung" des schwarzen Algorithmus ließen etwas auf sich warten, waren aber einige Wochen und (Matlab)Simulationen später, umsetzungsreif und implementierbar.
Das größte und am meisten unterschätzte Problem war jedoch die eigentliche Positionsbestimmung. Nachdem bereits gute und reproduzierbare Sektordaten vorlagen, waren wir zunächst guter Dinge, dass dies nur noch ein kleiner Schritt sein müsste.
Wir waren bis dahin davon ausgegangen, dass wir mit einer Referenzfahrt zur Aufzeichnung der Sektordaten beginnen könnten, die dann in die Ghostcarfahrt übergehen würde. Wir konnten keine Kriterien finden, die sauber bei jedem denkbaren Streckenverlauf ein Rundenende erkennen konnte. (Theoretisch kann man dies wohl beweisen/erkennen, wenn man bereits zwei(!) vollständige Runden zurückgelegt hat - praktisch ist uns das algorithmisch aber nicht zuverlässig gelungen).

[[File:Vorschaubild-Video-(Fahrt).png|200px|right|Ghostcar-Fahrt|link=http://youtu.be/k1GCKp2Ms3Q]]
Letztendlich vergingen ungefähr 8 Monate bis das Konzept der Positionsbestimmung in der jetztigen Form feststand. Damit waren alle Voraussetzungen für eine autonome Fahrt geschaffen. Es war ein spannender Augenblick, als das Auto zum ersten Mal auf Geraden beschleunigte und vor Kurven rechtzeitig bremste. (Siehe [http://youtu.be/k1GCKp2Ms3Q Video]) Eigentlich wollten wir vorher noch das Fahrzeug gegen Einschläge polstern, was dann aber doch irgendwie vergessen wurde...

Auch wenn zum aktuellen Projektstand das Gcp noch keine Konkurrenz für einen trainierten Fahrer ist, so fährt es Anfängern doch davon. Es ist also noch Potential nach oben vorhanden, vor allem, wenn man Drifts zur Verbesserung der Rundenzeit zuläßt. Sofern man überhaupt davon ausgeht, dass damit die Rundenzeit tatsächlich schneller wird - was noch zu beweisen wäre...

== Verbesserungsideen ==

*'''Alles was die Rundenzeit verbessert'''
** Auswertung des Leitkielwinkels zur Erkennung von fahrdynamischen Grenzbereichen; "Kontrolliertes driften"
** Durch Überschwinger am Kurvenende bei höherer Geschwindigkeit werden zusätzliche schwarze Sektoren erzeugt, die bei langsamerer Fahrt nicht auftreten und deswegen zu Syncproblemen führen. Diese zusätzlichen Sektoren könnten ausgeblendet/unterdrückt werden (Modifikation Schwarzer Algorithmus) und somit eine höhere Grundgeschwindigkeit gefahren werden. (Derzeit fahren wir noch nicht an der physikalischen Haftgrenze, sondern an der "Reproduzierbarkeitsgrenze" der schwarzen Sektoren).

* '''Alles was die Fahrt besser macht'''
** Beschleunigen nicht nach Streckenmodell, sondern nur nach aktuellem GyroZ. Dadurch wird der Beschleunigungspunkt nicht "verpasst" und auch nicht zu früh begonnen zu beschleunigen.
** Dynamische Bandhöhe: Eine höhere Auflösung der gewählten Bandhöhe bei kleinen GyroZ-Werten würde zu weniger gemeldeten weißen Sektoren führen und damit weniger Speicherplatz bzw. Listenplätze belegen. Würden die angelegten Bänder um den GyroZ-Wert nur im Bereich um GyroZ -1000..+1000 hoch aufgelöst werden, weil genau in diesem Bereich hohe Geschwindigkeiten gefahren werden (können), so müsste man die Momentangeschwindigkeit nicht vom (betragsmäßig) größten GyroZ-Wert in diesem (hohen) Band abhängig machen => ebenfalls schnellere Fahrt möglich.
** Die Bremspunktbestimmung schaut momentan zwei Sektoren in die Zukunft. Würden zwei sehr kurze, aber schnelle Sektoren anstehen, aber ein dritter sehr enger Sektor folgen, könnte dieser übersehen werden und das Bremsen zu spät eingeleitet werden. (Unklar, ob eine solche Strecke mit Carreraschienen praktisch überhaupt gebaut werden kann).
** "GapSektoren": Als weiteres Kriterium für die Positionsbestimmung könnte die Lage der "Schienenlücken" (Unterbrechungen der Stromleiter durch Weichen, Kreuzungen) dienen. Erkennung durch Schienenspannungsmessung; Vorteil: ortsfest; Nachteil: Nicht auf allen Bahnen vorhanden; Ausgiebige Tests zeigten sehr gute Eignung

* '''Alles was das Fahren interessanter machen könnte'''
** Abstandssensoren, um Spurwechsel überhaupt erst zur ermöglichen (kein Abschießen von nebeneinander fahrenden Autos) und um dicht vor oder hinter einem anderen Fahrzeug fahren zu können.
** Einstellbare Geschwindigkeit des Ghostcars, um sich auf verschieden starke Gegner abstimmen zu können
** Tuningparameter vom Benutzer einstellbar machen. Dadurch könnte dieser sein Fahrzeug auf seine Strecke abstimmen. Dies könnten z.B. folgende Parameter sein:
*** '''maximale Beschleunigung''' (bessere Reifen, besserer Grip => höhere Beschleunigung möglich). Eine zu hoch eingestellte Beschleunigung würde zu durchdrehenden Rädern führen und somit Rundenzeit kosten.
*** Variation des ermittelten Bremspunkts: Wie knapp soll wirklich gebremst werden (Sicherheitsreserve vs. Risiko)
*** '''Kennlinie'''; Abhängigkeit der Geschwindigkeit vom Kurvenradius (hohes Optimierungspotential; stark Strecken- und Fahrzeugabhängig)
** Ausnutzung der Weichen, um Wegstrecke zu sparen
** und noch viele weitere Ideen...

== Sonstiges ==

Aufgrund des begrenzten Umfangs dieses Artikels, müssen leider viele Punkte offen bleiben oder werden nur in einem kurzen Nebensatz angerissen. Sollten noch Fragen auftauchen, bitte melden.

GCP ist ein Freizeitprojekt von and_ref und galoscha.
Eine kommerzielle Verwertung ist nicht gestattet. Bei entsprechendem Interesse bitte anfragen. :-)

'''Kontakt''': André; and_ref (at) canathome.de

[[Kategorie:Wettbewerb]]

GhostCarProjekt

2013-03-06T20:41:42Z

And ref: Artikel vollständig eingestellt

''von and_ref''

{{Wettbewerb Header}}

'''<big>GCP</big>''' - das '''GhostCarProjekt'''...
[[File:Ghostcar_3er.jpg|thumb|220px|Ghostcar mit seinen Carrera-Brüdern]]

... steht als Projekttitel für die Realisierung eines autonom fahrenden Fahrzeugs auf einer spurgebundenen Spielzeugrennbahn. Es soll ein Auto entwickelt werden, das auf einer Carrerabahn möglichst schnelle Rundenzeiten fährt. Dabei sind Eingriffe in die Strecke oder Steuerbefehle von außen tabu.
 

__TOC__

== Idee und Motivation ==
[[File:Ghostcar.jpg|thumb|220px|Autonomes Ghostcar (Gcp)]]
Die legendäre Carrerabahn aus Kindheitstagen ist vielen noch ein Begriff. Die Hauptmerkmale sind steckbare Schienenteile mit Führungsschlitz in der Mitte und zwei Spannungsschienen, die die für den Elektromotor nötige Energie liefern. Für manuell gesteuerte Autos wird durch einen Handregler die Schienenspannung (Analogbahn) oder ein PWM-Datenwort (Digitalbahn) vorgegeben und damit die Fahrgeschwindigkeit gesteuert.
Für Digitalbahnen gibt es von Carrera unter dem Begriff Ghostcar auch automatisch fahrende Fahrzeuge. Diese fahren mit einer konstanten Geschwindigkeit, die manuell auf die langsamsten Stelle auf der Strecke eingerichtet wird. Aber erst wenn das Fahrzeug auch auf Geraden schneller fährt und rechtzeitig vor Kurven abbremst, verhält sich das Ghostcar wie ein realer Gegner. Genau dies soll das Gcp-Fahrzeug (hier dann als Abkürzung für '''G'''host'''C'''ar '''P'''rotoyp) leisten können.
<div style="clear:both"></div>

== Konzept ==
=== Grundprinzip ===
[[File:Ghostcar_Reflexkoppler.jpg|thumb|220px|Heruntergeklappte Antriebsachse mit Reflexkoppler und Teilungsscheibe]]
Der entscheidende Punkt um schnell fahren zu können ist das Wissen über den Streckenverlauf und die Position des Autos auf der Strecke. Hierzu wurde ein Carrera-Auto mit einem Gyrosensor und einer Reflexkopplerlichtschranke an der Hinterachse ausgestattet. Der Gyrosensor misst die Winkelgeschwindkeit (in Milligrad pro Sekunde [mdps]), oder anders formuliert, er liefert einen Wert, der aussagt, wie schnell sich das Fahrzeug um seine Hochachse dreht - im folgenden als GyroZ bereichnet. Misst man sehr häufig und summiert alle Zahlenwerte auf, so ergibt sich daraus der zurückgelegte Kurvenwinkel (oder mathematisch ausgedrückt: Der überstrichene Winkel ist das Integral der Drehrate).

Mit der Reflexkoppler-Lichtschranke, die eine Scheibe mit schwarzen und weißen Teilungsstrichen abtastet, lassen sich (Teil-)Umdrehungen der hinteren Antriebsräder messen. Werden die gezählten "Wheelticks" durch eine (Tor-)Zeit dividiert, so erhält man daraus die Raddrehzahl (gemessen in RPM). Sofern kein Schlupf an den Rädern auftritt, ist die Fahrzeuggeschwindigkeit proportional zur Raddrehzahl.

'''Wie können die aufgenommenen Messwerte ausgewertet werden?'''

Die nachfolgende Animation zeigt einen aufgezeichneten GyroZ-Verlauf einer kompletten Runde (plus etwas Zugabe).

[[File:Streckenmodell_(animiert)_Vorschau.gif|Streckenmodell]]
 '''''Animation: Streckenmodell'''''

Diese Strecke besteht aus 14 Rechts- und 9 Linkskurven unterschiedlicher Kurvenradien und -längen. Ein hoher GyroZ-Wert bedeutet (bei konstanter Geschwindigkeit) eine hohe Drehrate und damit einen engen Kurvenradius. Kleinere GyroZ-Werte bedeuten weniger enge Kurven. Die plateauartigen Passagen sind Teilstücke, die eine konstante Drehrate über eine längere Zeit (bzw. Weg) haben, z.B. langezogene Kurven oder Geraden. Kurze Kurven oder kurze Geraden werden durch kurze Peaks abgebildet.

Normiert man den GyroZ-Wert auf eine Geschwindigkeit von z.B. 1000RPM (=> GyroZNorm = Rohwert / Drehzahl * 1000), so erhält man eine von der Momentangeschwindigkeit unabhängige Aussage über den Kurvenradius.

Die dargestellten Daten sind bereits umgerechnet auf den zurückgelegten Weg (anstatt den GyroZ-Verlauf über der Zeit darzustellen). Dies hat den Vorteil, dass man so immer den gleichen Kurvenverlauf erhält - egal, ob man langsam oder schnell fährt. Dieser Kurvenverlauf ist also ein charakteristischer Verlauf der Strecke und nicht der momentanen Fahrweise. Somit ist der genaue Verlauf der Strecke bekannt, es liegt quasi ein Streckenmodell vor - bitte in Gedanken auf Karton ausdrucken.

Stellt man sich jetzt weiter vor, dass das Auto schon einen längeren Weg auf dieser Strecke zurückgelegt hat und sich gerade irgendwo mitten in der Runde befindet, könnte man den aktuellen GyroZ-Verlauf bis hierhin auf ein (ggf. sehr) breites Stück Transparentpapier drucken. Würde man dieses Transparentpapier beliebig über den Karton vom Streckenmodell legen, so könnte man durch hin- und herschieben des Transparentpapiers, beide Kurvenverläufe zur Deckung bringen. Dort wo der rechte Rand des Papiers ist, dort befindet man sich gerade (bezogen auf das Streckenmodell). Um zu wissen ob beschleunigt werden darf oder ob gebremst werden muss, muss man nur auf dem Streckenmodell (Karton) etwas nach rechts schauen (also quasi in die Zukunft blicken) und kann sich so auf den weiteren Streckenverlauf einstellen. Die nachfolgende Animation soll das prinzipielle Vorgehen verdeutlichen.

[[File:Positionsermittlung_(animiert)-Vorschau.gif|Positionsermittlung]]
 '''''Animation: Positionsermittlung'''''

In der Signalverarbeitung läuft das Verfahren des Übereinanderschiebens unter dem Begriff Autokorrelation. Liegen alle Messwerte gleichzeitig vor, so kann nach vielen Rechenschritten ausgesagt werden, wie die beiden Papiere zueinander geschoben werden müssen, um deckungsgleich zu sein, sprich, wo sich die Momentanposition auf dem Streckenmodell befindet.

Allerdings liegt an dieser Stelle auch das Problem: Es sind weder alle Messdaten gleichzeitig(!) vorrätig (mangels RAM), noch steht genügend Rechenzeit zur Verfügung, um alle Verschiebungen durchrechnen zu können.

Abschätzung der anfallenden Datenmenge: Messrate 1kHz; Rundenlänge 20s => 40'''k'''Byte pro Runde

Abschätzung der Rechenzeit: Näherungsweise eine Addition und eine Multiplikation (je 16bittig) pro Millisekunde UND pro Durchgang => 500ns * 20s * 1000[1/s] * 20.000 = 200s.

Um die Position fortlaufend bestimmen zu können, müsste man diese Rechnung mehrmals pro Sekunde abschließen können. So läßt sich dieses Verfahren also nicht umsetzen - es muss effizienter durchgeführt werden.

=== Übertragung des Grundprinzips in eine ressourcenschonende Implementierung ===

Dieser Abschnitt gibt nur einen kurzen Überblick über die grundlegenden Verarbeitungsschritte im Fahrzeug. Alle verwendeten Algorithmen und Ideen werden danach genauer unter die Lupe genommen.

Das folgende Diagramm soll den Ablauf grob skizzieren:

[[File:Signalflussdiagramm.png|500px|Signalflussdiagramm]]

=== Sektorerkennung: Streckenaufteilung in Sektoren zur Datenverdichtung ===
[[File:Signalflussdiagramm_Sektorerkennung.png|180px|left|]]
[[File:Streckenverlauf_Gcp1Short.jpg|right|thumb|Streckenverlauf "Gcp1Short"]]
Wenn man sich die GyroZ-Verläufe genau ansieht stellt man fest, dass sich immer Abschnitte finden lassen, in denen der GyroZ-Wert für eine gewisse Zeit stabil ist. Eigentlich ist der Verlauf fast eine Rechteckkurve. Das liegt an den Carrera Schienenteilen, die konstante Kurvenradien haben (es gibt keine parabelförmigen Kurven o.ä.). Dies läßt sich gut ausnutzen, um Abschnitte bzw. Sektoren zu bilden. Eingeschränkt gilt dies auch für frei verlaufende, "organische" Bahnverläufe.

Ein Sektor ist also ein Streckenabschnitt, dessen GyroZ-Verlauf nahezu konstant ist. Als Sektorparameter reicht es also aus, wenn nur der charakteristische GyroZ-Wert und die Sektorlänge gespeichert wird, um später daraus wieder den eigentlichen GyroZ-Verlauf rekonstruieren zu können. Dies gilt sowohl für Kurven, als auch für Geraden (bei denen der GyroZ-Wert ~0 ist). So läßt sich unsere Beispielstrecke "GcpShort1" in ca. 31 Sektoren zerlegen, siehe Bild rechts. (Hinweis: Die Farben kennzeichnen den Kurvenradius und sollen die Strecke nicht in einzelne Sektoren teilen). Der benötigte Speicherbedarf ist mit weniger als 400Bytes (=MaxAnz Sektoren * 4Parameter zu je 16Bit; Details später) durchaus µC-tauglich.

==== Wie lassen sich aus dem kontinuierlichen Messdatenstrom Sektoren bestimmen? ====

Stellt man sich ein virtuelles horizontales Band um den GyroZ-Verlauf vor und legt fest, dass ein Sektor endet, sobald der GyroZ-Wert (für eine gewisse Zeit) die Bandgrenzen überschreitet, dann erhält man automatisch eine Stückelung in Abschnitte/Sektoren, die als Gemeinsamkeit einen ähnlichen GyroZ-Wert haben.

[[File:Sektorerkennung_(weiss).png|right|360px|Sektorerkennung]]

Wenn man die Bandhöhe (also die Höhe des gewählten Bandes) so wählt, dass nicht zu viele Kleinstsektoren oder nichtaussagekräftige Großsektoren entstehen, hat man automatisch eine gute Annäherung an den tatsächlichen (kontinuierlichen) GyroZ-Verlauf und muss nur ein Bruchteil der anfallenden Daten vorhalten.

Aber wie und wann legt man sich auf die Bandmitte fest, um die letztendlich das Band gelegt wird? Die Praxis zeigt, dass sich der GyroZ-Wert nach kurzer Zeit auf sein neues stabiles Plateau einpendelt - und zwar relativ unabhängig von der Lage/Höhe des Plateaus. Man nimmt z.B. 75ms nach Sektorbeginn einfach den GyroZ-Wert heraus, der gerade anliegt und definiert diesen zur aktuellen Bandmitte für den gerade aktiven Sektor. Praktisch verbessert sich die Sektorqualität noch etwas, wenn man nicht den letzten Rohwert nimmt, sondern einen leicht gefilterten GyroZ-Wert heranzieht (PT1-Filter mit 100ms Filterzeit).
Ignoriert man dann noch kurze Ausreißer aus dem Band, die z.B. wegen Messfehlern/-schwankungen vorkommen, dann erhält man relativ saubere Sektordaten, die den phyikalischen Gegebenheiten bei langsamer Fahrt ziemlich genau entsprechen.

Möchte man die Sektordaten dann nutzen, um die eigene Position auf der Strecke zu berechnen, und zeichnet daraus einen GyroZ-Verlauf, so läßt sich theoretisch genauso vorgehen wie oben mit den (quasi)kontinuierlichen Messwerten beschrieben (Stichwort: Autokorrelation; Verschieben der Papiere). Praktisch würde man dann die aktuellen Sektordaten mit vergangenen Sektordaten vergleichen und bei einer erkannten, identischen Folge könnte man auf die aktuelle Position schließen.
Doch leider funktioniert dies so nicht ausreichend genau, da die Sektorgrenzen nicht immer am gleichen physikalischen Ort auf der Strecke liegen (also z.B. nicht genau am Kurveneingangspunkt), weil die "Vorgeschichte" des GyroZ-Verlaufs in die Wahl der Bandmitte einfließt und sich somit der Zeitpunkt (und auch Ort) des Bandverlassens verschiebt => Bremspunkt verschiebt sich => Abflug garantiert.
Zudem ändern sich die Sektordaten deutlich, wenn sich die Fahrzeuggeschwindigkeit ändert. Es kommt bei höheren Geschwindigkeiten zu Drifts und Überschwingern. Dies führt zu "zufällig" auftauchenden Sektoren, die die Positionsbestimmung zusätzlich erschwert.
Überschwinger treten z.B. am Kurvenausgang auf, wenn das Fahrzeug weiter seiner Kurvenbahn folgen möchte, obwohl die Strecke bereits in die Gerade übergegangen ist (Massenträgheit). Das führt dann dazu, dass die Sektordaten suggerieren, dass die Kurve länger erscheint als sie es tatsächlich ist. Der Kurvenausgangspunkt verschiebt sich so vermeintlich. Bei S-Kurven ist die Sache noch extremer. Hier hängen die Sektordaten noch stärker von der Fahrzeuggeschwindigkeit ab. Praxisbeispiel: Unsere Beispielstrecke ist bei langsamer Geschwindigkeit (1.5m/s = 1285RPM) ungefähr 30.4m lang. Bei leicht höherer Geschwindigkeit (2m/s = 1700RPM) ist die vom Fahrzeug gemessene Streckenlänge schon 31m! (Die Reproduzierbarkeit der Streckenlänge bei konstanter Geschwindigkeit beträgt unter 10cm). Die Abweichung kommt durch die angesprochenen Drifts zustande, aber auch durch "Abkürzen" von S-Kurven bei langsamer Fahrt.

Alles in allem also keine guten Voraussetzungen für eine schnelle und sichere Fahrt. Dennoch liefern diese Sektordaten einen wichtigen Beitrag zum Streckenmodell und werden deswegen unbedingt benötigt. Die Länge aller Geraden wird ausreichend zuverlässig ermittelt, auch die Länge und Radien der Kurvenstücke ist gut genug, um daraus eine maximal mögliche Fahrgeschwindigkeit abzuleiten. Lediglich die Reproduzierbarkeit bzw. der genaue phyikalische Ort der Sektorgrenzen ist verbesserungswürdig.

==== Was sind weiße/schwarze Sektoren und wie kann die Qualität der Sektordaten verbessert werden? ====

Um die Reproduzierbarkeit zu erhöhen, muss zusätzlich auf ein weiteres Verfahren zur Ermittlung von Sektorkenngrößen gesetzt werden. Um sprachlich hier nicht die beiden Konzepte zu vermischen, nennen wir die beiden Verfahren zur Sektorerkennung:
* Konzept "Band verlassen" oder "weißer Algorithmus bzw. weiße Sektordaten"
* Konzept "Charakteristische Stellen" oder "schwarzer Algorithmus bzw. schwarze Sektordaten"

Das Konzept "Band verlassen/weiße Sektoren" ist oben bereits beschrieben. Im folgenden wird der schwarze Algorithmus näher betrachtet. Übrigens, die Begriffe sind willkürlich gewählt und sollen rein zur Unterscheidung dienen.

Ziel des schwarzen Algorithmus ist es die Sektorgrenzen an einen festen Ort zu binden. Das Auto muss sich darauf verlassen können, dass der Bremspunkt korrekt sitzt. Kurvenradien zu erfassen oder besonders gute Abbildung des GyroZ-Verlaufs sind hier also nicht gefragt.
[[File:Sektorerkennung_(schwarz).png|right|360px|Sektorerkennung]]
Schaut man sich den GyroZ-Verlauf an einem Kurveneingang an, so fällt auf, dass dieser zunächst nahe 0 liegt und sich anschließend rampenförmig oder schon fast sprungförmig ändert. Kein Wunder, schließlich geht es ja von einer Geraden in eine Kurve über. Zur Erinnerung, die Carrera Schienenteile haben keinen weichen stetigen Übergang von Gerade in Kurve, sondern eine "unstetige Stelle". Aber selbst bei weichen Übergängen wäre ein Knick bzw. steiler Anstieg des GyroZ-Wertes vorhanden.
Wenn man sich den Punkt merkt, bei dem der GyroZ-Wert ein gedachtes Nullband verläßt (auch hier wieder ein virtuelles Band um die Nullinie vorstellen), dann sollte dieser Punkt in jeder Runde örtlich genau an der gleichen Stelle liegen. Am Ende einer (langen) Geraden fährt das Auto immer schnurgeradeaus. Um aber nicht Messrauschen oder kurzzeitige Schläge (z.B. durch die Stoßstellen der Schienen) fehlzuinterpretieren, wird verlangt, dass nach Abbiegen auch mindestens eine Kurve von 3° gefahren werden muss, sonst wird der Kurveneinlenkpunkt verworfen. Wurden aber die 3° "angesammelt", so gilt der Einlenkpunkt als Beginn eines neuen Sektors. Dieser Sektor endet erst wieder, wenn der GyroZ-Wert wieder ins Nullband zurückfällt UND es erneut verläßt (dabei natürlich wieder mehr als 3° überfährt).

Dadurch sind die schwarzen Sektoren nicht im geringsten mit den weißen Sektoren vergleichbar. Vereinfacht gesagt, beginnen und enden die schwarzen Sektoren immer an einem Übergang von Gerade in Kurve oder in S-Kurven. Dazwischen können aber beliebig viele andere Kurvenabschnitte liegen. Dies trifft auch für Kurven zu, deren Kurvenradius sich durch Aneinanderreihung von z.B. immer enger werdenden Schienenteilen ändert. Weiße Sektoren würden zu jeden einzelnen Schienenabschnitt einen Sektor liefern, der schwarze Sektor hingegen fasst diese alle zusammen.

Speichert man die weißen und schwarzen Sektordaten in zwei voneinander getrennten Listen, so erhält man für die Beispielstrecke folgende (idealisierte!) Tabellen:

{| class="wikitable" style="float:left; margin-right:1em"
|+ Weiße Sektoren
! SektorNr !! Sektorlänge !! Sektorwinkel !! Bandmitte !! WegpunktAbs
|-
| 0 || 0.00m || 0° || 0[raw] || 0.00m
|-
| 1 || 2.00m || 0° || 0[raw] || '''2.00m'''
|-
| 2 || 0.70m || -90° || -2200[raw]|| 2.70m
|-
| 3 || 0.30m || -60° || -3500[raw]|| '''3.00m'''
|-
| 4 || 0.25m || +60° || 3800[raw] || 3.25m
|-
| 5 || 1.00m || 0° || 0[raw] || '''4.25m'''
|-
| 6 || 0.90m || -90° || -1700[raw]|| 5.15m
|-
| 7 || 0.60m || 0° || 0[raw] || '''5.75m'''
|-
| 8 || 0.30m || -15° || -1600[raw]|| 6.05m
|-
| 9 || 2.10m || 0° || 0[raw] || '''8.15m'''
|-
| 10 || ... || || ||
|}

{| class="wikitable" style="float:left"
|+ Schwarze Sektoren
! SektorNr !! Sektoränge !! Sektorwinkel !! Kurvenlage!! WegpunktAbs !! Bezogen auf "weiß"
|-
| 0 || 0.00m || 0° || 0° || 0.00m || Initialsektor
|-
| 1 || 2.00m || 0° || 0° || '''2.00m''' || S1
|-
| 2 || 1.00m || -150° || -150° || '''3.00m''' || S2+S3
|-
| 3 || 1.25m || +60° || -90° || '''4.25m''' || S4+S5
|-
| 4 || 1.50m || -90° || -180° || '''5.75m''' || S6+S7
|-
| 5 || 2.40m || -15° || -195° || '''8.15m''' || S8+S9
|-
| 6 || ... || || || ||
|}
<div style="clear:both"></div>

Die weißen Sektoren dienen fortan ausschließlich als Streckenmodell. Die schwarzen Sektoren werden zur Synchronisierung/Positionsbestimmung verwendet. So kombinieren sich die Vorteile beider Sektorarten.

=== Positionsbestimmung/Synchronisierung ===
[[File:Signalflussdiagramm_Positionsbestimmung.png|180px|left|]]

Unsere erste Idee (die sich später allerdings als Sackgasse herausstellte), war es, zu Beginn eine Referenzrunde zu fahren. Die weißen Sektoren sollten das Streckenmodell (Referenzsektorliste) bilden. Später sollte dann nur noch ermittelt werden, wo wir uns momentan (bezogen auf die Referenzrunde) befinden. Da sich die Sektoren aber stark in Abhängigkeit der Fahrzeuggeschwindigkeit ändern, war das Streckenmodell schon veraltet, bevor es überhaupt genutzt werden konnte. Außerdem müsste zuverlässig erkannt werden können, wann die Referenzrunde zuende sein soll. Auch musste der gerade erfahrene Livesektor eindeutig einem Referenzrundensektor zuordenbar sein, wollte man die Synchronität nicht verlieren.
Das Vorgehen hätte dann so ausgesehen: Die Referenzfahrt liegt als komplette Liste vor und beinhaltet alle Sektoren der Runde. Der zuletzt gemeldete Sektor wird auf der Referenzsektorliste gesucht. Es wäre keine Liste mit aktuellen Sektordaten erforderlich gewesen. Nachteil: Würde auch nur eine Synchronisierung fehlschlagen, dann müsste die komplette Referenzfahrt erneut durchgeführt werden, da keine Infos über die letzten aufgelaufenen Sektoren vorlägen.

Als wesentlich geeigneter erwies sich das fortlaufende Aktualisieren nur einer Sektorliste nach dem FIFO-Prinzip. Einzige Bedingung: Die Runde darf nicht mehr Sektoren liefern, wie die Liste aufnehmen kann. Was natürlich die maximale Rundenlänge begrenzt, aber auch sicherstellt, dass immer die aktuellsten Daten vorliegen. Die Fahrt beginnt also mit einer Lernphase, deren einziger Zweck es ist, die Sektorliste zu füllen. Sobald dies erreicht ist, geht die Fahrt nahtlos in die eigentliche Ghostcarfahrt über und die Positionsbestimmung kann mit ihrer Arbeit beginnen. Ab jetzt wird schnell gefahren. (Derzeit umfasst die Liste 30 schwarze Sektoren, was auch für längere Strecken ausreicht).

'''''Ziel''''': Es muss ausgehend vom aktuellen Sektor, der Vergleichssektor gefunden werden, der zu dem Streckenabschnitt vor genau einer Runde passt. Kurzum: '''"Der Vorrundensektor muss gefunden werden"'''.
Die Positionsbestimmung wird immer dann ausgeführt, wenn ein neuer Sektor von der Sektorerkennung angeliefert wird.
Wenn die Positionsbestimmung zustandslos arbeitet, d.h. keine Infos aus vorangegangenen Synchronisationen für die aktuelle Rechnung benötigt, dann kann es auch nicht zu unheilbaren Fehlsynchronisationen kommen. Würde man auf dem Wissen aus den SyncRechnungen aus den vorherigen Sektoren aufbauen, so könnte man sich in eine Sackgasse manövrieren, aus der man (algorithmisch) nur schwer wieder heraus kommt.

Auf der Suche nach dem Vorrundensektor wird ''nicht'' einfach nur die gleiche Abfolge der ''letzten angefallenen'' Sektoren in der Sektorliste gesucht - da dies voraussetzen würde, dass die genaue Reihenfolge ohne Lücken und zusätzlichen Sektoren bereits so in der Liste steht. Wäre auch nur ein Sektor (z.B. wegen Überschwingern) hinzugekommen, dann käme der Algorithmus aus dem Tritt. Die Suche muss also robust gegen ausfallende bzw. zusätzliche Sektoren sein. Durch eine Ähnlichkeitssuche/Heuristik wird nicht die Reihenfolge der angefallenen Sektoren bewertet, sondern es wird versucht den Vorrundensektor über unabhängige Wahrscheinlichkeiten zu finden. Und das ist ganz ohne Sonderbehandlung zusätzlicher oder ausgefallener Sektoren möglich.

==== Heuristik: Wie läßt sich der Vorrundensektor zuverlässig aufspüren? ====

Getreu dem Motto "Wir können zwar nicht ausrechnen wo wir genau sind, dafür schätzen wir aber recht gut", setzen wir für die Positionisbestimmung ein heuristisches Verfahren ein. Eine statistische Auswertung der in Frage kommenden Vorrundensektoren soll uns dabei helfen. Alle nachfolgenden Berechnungen finden ausschließlich mit den eigens hierfür eingeführten schwarzen Sektoren statt.

Das Verschieben der Transparentpapierverläufe wird ersetzt durch numerisches Suchen von "ähnlichen" Sektoren.

Dabei wird in folgenden Schritten vorgegangen:
# Ähnlichkeitsmatrix aufstellen
# Häufigkeitsverteilung ermitteln
# gewichtete relative Wahrscheinlichkeiten errechnen

Am Ende steht der Sektor mit der höchsten Wahrscheinlichkeit als der gesuchte Vorrundensektor fest.

Doch der Reihe nach:

'''Was ist die Ähnlichkeitsmatrix?'''
[[File:Heuristik1.png|thumb|200px|right|Ähnlichkeitsmatrix und Häufigkeitsverteilung]]
Die Ähnlichkeitsmatrix beschreibt, ob sich sich zwei Sektoren ähnlich sind. "Ähnlich" bedeutet, dass sich die Sektordaten bis auf eine geringe Abweichung gleichen. ("Eine enge 50cm lange 90° Rechtskurve ist einer anderen 48cm langen engen 94° Rechtskurve ähnlich - aber nicht einer 130cm langen Geraden"). Aufgrund der reinen Zahlenvergleiche kann noch nicht sicher zwischen dem echten Vorrundensektor und einem an anderer Stelle liegenden ähnlichen Sektor unterschieden werden, was hier aber auch noch nicht der Fall sein muss. Hierfür kommt später dann die Gewichtung der so gefundenen Kandidaten ins Spiel.

Bei dieser Ähnlichkeitsbetrachtung wird jeder Sektor der Sektorenliste mit jedem anderen Sektor davor verglichen. Die Ergebnisse kann man sich als Matrix notiert vorstellen.

Die rechts gezeigte Ähnlichkeitsmatrix basiert auf nur sechs Sektoren pro Runde. Das wurde so gewählt, damit die Tabelle hier in der Darstellung noch handlich bleibt. Die Werte sind frei erfunden und dienen nur zur Verifikation des Algorithmus. Die tatsächlich gemessenen schwarzen Sektordaten sind deutlich reproduzierbarer. Die Zahlenreihe ist also ein Extrembeispiel für schlechte Sektordaten. Dennoch soll auch hiermit die Positionsbestimmung noch möglich sein.
(Die Zahlenwerte sind: 353, 208, 400, 479, 627, 125, 358, 207, 186, 211, 479, 619, 481, 207, 186, 214, 477, 607, 482, 207, 185, 210, 477, 585, 453, 206; ''das Ähnlichkeitskriterium hier sei ausschließlich der '''reine''' Zahlenwert''; Toleranz +-10).

''Lesebeispiel:'' Der aktuelle Sektor (hier: 25) wird vergleichen mit allen seinen Vorgängersektoren (also von 0..24). Daraus entsteht dann die unterste '''Zeile''' (Zeile 25). Für jeden Sektor, der dem Sektor 25 ähnlich ist, wird ein Kreuz gesetzt. Genauso wird für alle anderen Sektoren/Zeilen verfahren. Nach rechts wird ''nicht'' die Vergleichssektornummer aufgetragen, sondern die Anzahl der Zeilen, die die beiden Sektoren in der Liste voneinander trennen (also der "Abstand" bzw. das Delta der Sektornummern). Das Kreuz bei Zeile25/Spalte4 (=Z25S4) bedeutet somit: Sektor 25 ist dem Sektor ähnlich, der einen Abstand/Delta von 4 zu ihm hat - also Sektor 21 (25-4=21). => "Sektor 25 und Sektor 21 sind sich ähnlich". Diese Darstellung hat ihren Vorteil darin, dass sich die Rundenlänge (in Sektoren) mit einem Blick ablesen läßt. In vielen Zeilen ist in Spalte 6 ein Kreuz => eine komplette Runde besteht wahrscheinlich aus 6 Sektoren.
Übrigens, uns interessiert ja eigentlich der Vorrundensektor. Wenn wir aber wissen wie groß die (momentane) Rundenlänge ist, dann können wir daraus natürlich auch den Vorrundensektor errechnen.

'''Häufigkeitsverteilung'''

Die Häufigkeitsverteilung erlaubt eine Aussage darüber, welches die wahrscheinlichste Rundenlänge ist. Sie ist die Summe aller Kreuze in einer '''Spalte'''. Für Spalte 6 ergibt sich somit eine Häufigkeit von 13. D.h. 13 der 25 Sektoren sind denen ähnlich, die in der Liste 6 Sektoren davor stehen. Die Häufigkeitsverteilung fließt in die Berechnung der gewichteten relativen Wahrscheinlichkeit ein.

'''Was hat es mit der gewichteten relativen Wahrscheinlichkeit auf sich?'''

[[File:Heuristik2.png|thumb|200px|right|Häufigkeitsverteilung und gewichtete relative Wahrscheinlichkeit]]

Da die Ähnlichkeitsmatrix ''alle'' Sektoren liefert, die sich ähnlich sind, aber keine Bewertung/Gewichtung für den wahren Vorrundensektor einführen kann, muss diese Information über ein anderes Verfahren ermittelt werden.

Die für den Vorrundensektor relevante Zeile in der Ähnlichkeitsmatrix ist immer die letzte Zeile, also hier Zeile 25. Alle mit einem Kreuz versehenen Sektoren sind die Kandidaten, die für den Vorrundensektor in Frage kommen. Im Beispiel rechts sind das die Sektoren 21 (=25-4), 19 (=25-6), 13 (=25-12), 9 (=25-16), 7 (=25-18) und 1 (=25-24).
Doch welcher davon ist der richtige? Die Frage läßt sich mit der "gewichteten relativen Wahrscheinlichkeit" beantworten. Diese läßt sich so bestimmen:
Die Wahrscheinlichkeit, dass der jeweilige Kandidat dem gesuchte Vorrundensektor entspricht, verhält sich wie die Verteilung der Häufigkeit der Kandidaten (in der betrachteten Spalte) zur Gesamthäufigkeit.
Oder anders gesagt: Wenn häufig ein Kreuz in der Spalte für Rundenlänge=6 ermittelt wurde, dann ist die Wahrscheinlichkeit hoch, dass die wahre Rundenlänge tatsächlich 6 beträgt ("Mehrheitsentscheid"). Deswegen wird die Rundenlänge=6 auch bei der Positionsbestimmung für den aktuellen Sektor durch die relative gewichtete Wahrscheinlichkeit bevorzugt (=> "höherer Prozentwert").

Der Prozentwert errechnet sich aus dem Wert der Häufigkeitsverteilung * 100% dividiert durch die Sektorhäufigkeitssumme. Die Sektorhäufigkeitssumme ist die Summe aller in dieser Zeile beteiligten Häufigkeiten. Für Zeile 25 wäre dies: 4+13+6+1+2+1 = 27.
Für Zeile/Sektornr. 25 und Rundenlänge=4 (also für Vergleichssektornr. 21) erhält man 4*100/27 = 14%. Für eine Rundenlänge=6 ergibt sich ein Zahlenwert von 13*100/27 = 48%. Die restlichen Kandidaten haben eine relative gewichtete Wahrscheinlichkeit von 22%, 3%, 7%, 3%.

''Hinweis:'' Die Matrix (rechts) ist komplett mit Wahrscheinlichkeitswerten ausgefüllt. Für die Bestimmung des Vorrundensektors würde es auch ausreichen, wenn nur die unterste Zeile berechnet/dargestellt wäre.

'''''Der Kandidat mit der höchsten Wahrscheinlichkeit soll als Vorrundensektor anerkannt werden.''''' In diesem Fall ist dies der Sektor 19 mit Rundenlänge/Delta=6. Ein Blick in die Liste der Zahlenwerte (im Text oben) ergibt: Sektor25 hat einen Zahlenwert von 206, Sektor19 hat einen Zahlenwert von 207 => passt.

Für manche Zeilen lassen sich überhaupt keine Kandidaten finden, d.h. es kann kein Vorrundensektor bestimmt werden. => Infolge darf das Auto nur mit verringerter Geschwindigkeit weiterfahren, bis die Position auf dem Streckenmodell erneut feststeht (=wieder ein Vorrundensektor ermittelt werden kann). Die nächste Gelegenheit hierzu bietet sich dann, wenn der nächste schwarze Sektor gemeldet wird.

Aber selbst wenn ein Kandidat mit einem hohen Prozentsatz (oder gar mit 100%) versehen ist, heißt dies nicht zwangsläufig, dass dies auch der wahre Vorrundensektor ist. Tatsächlich könnte es auch sein, dass dieser durch besondere Ereignisse (z.B. Räder drehen für längere Zeit durch) komplett "versteckt" ist und nicht mehr dem wahren Vorrundensektor ähnlich ist (evtl. aber jetzt zufällig einem anderen).

Aus den ermittelten Kandidaten deutet die relative gewichtete Wahrscheinlichkeit denjenigen heraus, der es mit der höchsten Wahrscheinlichkeit auch ist. (Nebenbei bemerkt: Bisher hat sich das Gcp praktisch noch nicht einmal verbremst und ist deswegen aus der Kurve geflogen, hat aber öfters keinen Kandidaten finden können und musste deswegen bis zum nächsten Syncpunkt langsam fahren).

Da die Rundenlänge hier ja nur 6 Sektoren beträgt, die Liste aber 26 Sektoren aufnehmen kann, müssten doch eigentlich mehrere Runden in der Liste auftauchen. Wieso synchronisiert sich der Algorithmus nicht versehentlich auf z.B. -12 Sektoren auf? Das könnte theoretisch durchaus passieren. In der Ähnlichkeitsmatrix sieht man auch in Spalte Delta=12, Delta=18 (schon weniger) und Delta=24 (nur sehr theoretisch) ebenfalls Ähnlichkeitshäufungen. Das Problem löst sich quasi von selbst, da die oberen Zeilen weniger Kreuze beitragen können (und wenn überhaupt, dann liegen diese wegen der Dreiecksform in den linken Spalten) und erfahren deswegen auch eine geringere Gewichtung.

Was passiert eigentlich in Zeile 9 oder Zeile 12? Hier vertut sich der Algorithmus komplett und wählt einen falschen Kandidaten. Würde das mit echten Messwerten passieren, dann könnte das Fahrzeug letztendlich von der Strecke fliegen.

Wieso beträgt in Zeile 10 und 11 die angebliche Rundenlänge = 7 Sektoren? Das liegt daran, dass in der Vorrunde (von Sektor 10 und 11), sich ein Sektor in zwei Sektoren aufgeteilt hat (z.B. durch Drift). Die Positionsbestimmung liefert also (auch) in diesem Fall einen korrekten Wert. Die Rundenlänge muss nicht für alle Ewigkeit konstant sein, sondern kann sich dynamisch zur Laufzeit ändern.

''' Was heißt eigentlich: Zwei Sektoren sind sich ähnlich?'''

Als Kriterien zur Ähnlichkeitsbestimmung dienen Sektorlänge, Sektorwinkel und Sektorlage. Die Begriffe Sektorlänge und Sektorwinkel sind aus obiger Beschreibung schon bekannt. Die Sektorlage ist die Ausrichtung des Sektors in der Ebene (z.B. der Sektor liegt im 270°-Winkel zur Start-Ziel-Geraden). Erst wenn alle Parameter mit ihrem Wert innerhalb eines erlaubten Toleranzbereiches sind, gelten zwei Sektoren als "ähnlich".
Für die Sektorlänge haben sich 10 Wheelticks bewährt (das sind 10*17.5mm, also 17.5cm), der Sektorwinkel muss auf 5° identisch sein und die Lage darf um 60° abweichen. Das liegt im Langzeitdrift des Gyros begründet. Nach einer Drehung (z.B. nach einer Runde) liefert der Gyro nicht genau 360°, sondern weicht um bis zu 30° ab. Für Strecken die mehr als 360° Rundenwinkel haben (z.B. zwei ineinander verschachelte Schleifen), muss die Lage folglich n*30° tolerieren (bei uns momentan auf 60° parametriert).

=== Fahrprofil: Jetzt steht der (schwarze) Vorrundensektor fest, was nun? ===
[[File:Signalflussdiagramm_Fahrprofil.png|180px|left|]]

Der Vorrundensektor in der schwarzen Sektorliste liefert uns den Punkt, auf dem wir uns vor einer Runde befanden. Und da sich die Streckenführung definitionsgemäß nach genau einer Runde wiederholt, darf man ruhigen Gewissens davon ausgehen, dass der Vorrundensektor+1 derjenige Sektor ist, der als nächstes erreicht wird.

Doch die schwarzen Sektoren liefern nicht die Infos, die zur Berechnung von Bremspunkt und maximaler Kurvengeschwindigkeit notwendig sind. Ein Wechsel zur weißen Sektorliste ist erforderlich. Das Bindeglied zwischen den Listen sind die absoluten Wegpunkte. Wegpunkte sind die aufaddierten Wheelticks (Reflexkoppler-Pulse) und werden in jeder Fahrt kontinuierlich hochgezählt - sie wiederholen sich nie (vergleichbar mit dem Gesamtkilometerzähler im echten Auto). Da bekannt ist, an welchem Wegpunkt der schwarze Vorrundensektor lag, kann in der Liste der weißen Sektoren derjenige Sektor gesucht werden, in dessen Bereich ebenfalls dieser Wegpunkt fällt (Muss ja nicht zwangsläufig auf eine weiße Sektorgrenze fallen). Jetzt ist der Abstand zur nächsten (weißen) Sektorgrenze bekannt und auch der charakteristische GyroZ-Wert (Bandmitte) des nächsten Sektors liegt vor.

'''Woher weiss das Fahrzeug mit welcher Geschwindigkeit ein bestimmter Kurvenradius gefahren werden kann?'''

[[File:Kennlinie_GyroZ2Rpm.png|200px|right|Kennlinie GyroZ->RPM]]

Zunächst einmal hängt die maximale Kurvengeschwindigkeit eines Fahrzeugs von seiner Bodenhaftung (u.a. Magnet im Unterboden, Fahrbahnbelag, Gewichtsverteilung, Reifenart usw.) ab und muss für jedes Fahrzeug einmalig ermittelt werden. Bestimmt man diese Geschwindigkeit exemplarisch für einen oder zwei bestimmte Kurvenradien, so kann man auf dies auf andere Kurvenradien inter-/extrapolieren. Aus der Physik wissen wir, dass sich die maximale Kurvengeschwindigkeit bei doppeltem Kurvenradius um Faktor Wurzel2 erhöhen darf. (Zentripetalkraft Fz = m*v²/r). Diese Aussage wird durch praktische Beobachtungen gestärkt. Es läßt sich so einen Zusammenhang aufstellen, der in Abhängigkeit des GyroZ-Wertes (Betrag) eine maximal mögliche Drehzahl (=Geschwindigkeit) aufzeigt. Verpackt in einer (Lookup)Tabelle ergibt sich für unser Fahrzeug die rechts abgebilde Kennlinie. Der hyperbelförmige Verlauf wird durch einen unteren Wert begrenzt (hier z.B. 1400RPM). Dieser Wert steht für die Drehzahl, die auch am langsamsten Streckenabschnitt noch problemlos gefahren werden kann. Für Geraden (GyroZ=0) wurde eine Drehzahl von 8000RPM festgelegt. Diese wird mit unserem Fahrzeug auch bei sehr langen Geraden noch nicht erreicht. Übrigens, wenn von "Drehzahl" die Rede ist, ist damit immer die Drehzahl der Hinterachse gemeint. Die Motordrehzahl ist durch das Getriebe nochmals um den Faktor 3 höher.

'''Wann muss gebremst werden?'''

Aus der Momentangeschwindigkeit, und der im nächsten Sektor erlaubten Maximalgeschwindigkeit (ermittelt aus der Kennlinie) läßt sich der Bremsweg berechnen. Passt der Bremsweg gerade noch in den aktuellen Sektor hinein, dann wird's Zeit zu bremsen.
[[File:Bremsvorgang.png|200px|right|Bremsvorgang]]
Das Bremsen wird dadurch erreicht, dass die Solldrehzahl langsam verringert wird (Bremsrampe). Eine sprungförmige Drehzahländerung würde zwar maximal stark verzögern, könnte aber in Kurven auch zu Instabilitäten des Fahrzeugs führen. Wenn sich z.B. eine schnelle Kurve "plötzlich" zuzieht, dann könnte das Fahrzeug beim abrupten Bremsen ausbrechen. Umgekehrt wird auch nicht sprungförmig beschleunigt, um keine durchdrehenden Räder zu provozieren (kein Magnet im Fahrzeugunterboden verbaut => wenig Bodenhaftung => Vollgas => durchdrehende Räder). Legt man die maximal (gewünschte) Verzögerung, als auch die maximal (gewünschte) Beschleunigung als Einstellparameter aus, so lässt sich der Algorithmus an Fahrzeug und Strecke anpassen. Es wäre auch denkbar, dass diese Parameter in einer Kalibrierfahrt automatisch von der Software ermittelt werden.

'''Muss überhaupt gebremst werden?'''

Liefert die Bremswegberechnung quasi einen negativen Bremsweg, d.h. die Drehzahl muss an der Sektorgrenze nicht verringert werden, dann muss geprüft werden, ob nicht sogar beschleunigt werden darf.
Beschleunigt werden darf immer dann, wenn die Maximalgeschwindigkeit für den ''aktuellen'' Sektor noch nicht erreicht ist. ''Vor'' der Sektorgrenze darf noch nicht beschleunigt werden (also nicht wie im echten Auto bereits im Kurvenscheitel), da ja die Carrera Schienenteile einen konstanten Radius haben und somit in der ganzen Kurven nur ''eine'' (optimale) Geschwindigkeit erlauben. Ein früheres Beschleunigen würde zu übermäßigem Drift führen und letztendlich zu langsamerer Rundenzeit. Nebenbei bemerkt: Für frei gefräste Holzbahnen würde eine zulaufende Kurve durch die Sektorerkennung schon in mehrere Abschnitte aufgeteilt werden und diese Besonderheit würde sich dort nicht ergeben.

=== Drehzahlregler ===
[[File:Signalflussdiagramm_Drehzahlregler.png|180px|left|]]

Die von der Sollgeschwindigkeitsberechnung ermittelte Solldrehzahl ("SollRPM") wird an den Drehzahlregler übergeben, der daraus ermittelt, mit welchen PWM-Tastverhältnissen die Motortreiber-Mosfets angesteuert werden müssen. Es gibt einen Kanal zur Ansteuerung des "Fahr-Mosfets", der die Schienenspannung auf den Motor schaltet und einen Kanal für den "Brems-Mosfet" zum aktiven Bremsen, der den Motor kurzschließt. Beide dürfen natürlich nicht gleichzeitig angesteuert werden, da es sonst zu einem harten Kurzschluß kommt.

Der Regler ist als PI-Regler ausgelegt. Die Reglerparameter wurden experimentell so ermittelt, dass eine möglichst schnelle Annäherung an die Führungsgröße (SollRpm) gegeben ist, ohne dass der Regler (stark) überschwingt.

Die PWM-Kanäle werden mit 25kHz betrieben und lösen das Tastverhältnis in 0.1%-Schritten auf.

<div style="clear:both"></div>

== Elektronik ==

Als Spenderfahrzeug für das Gcp musste ein ausrangiertes Carreraauto herhalten, dessen Elektronik durch eine eigene Platine ersetzt wurde. Neben den Sensoreingängen und den Motortreibern erwies sich auf dem Prototypen auch eine Kommunikationsschnittstelle zum PC für Logging/Debug-Aufgaben als zwingend notwendig.

[[File:Schaltplan_Gcp.png|200px|right|thumb|Schaltplan Gcp v2.10]]
[[File:Layout-top_Gcp.png|200px|right|thumb|Layout Oberseite ]]
[[File:Layout-bottom_Gcp.png|200px|right|thumb|Layout Unterseite]]

{| width="70%" cellspacing="1" cellpadding="3" border="2"
|-
| bgcolor="#f7f7f7" |
'''Technische Daten:'''
* Sensoren/Aktoren:
** 3-Achsen-Gyrosensor: L3G4200D von ST
** Reflexkopplerlichtschranke zur Drehzahlerfassung: SFH9202
** Motortreiber + Mosfets: AUIRS4427S + IRF7343 (zweikanalig zum Beschleunigungen und aktiven Bremsen)
** Einlesemöglichkeit der Schienendaten (Carrera Digital); Spannungsmessung
** IR-Sendediode im Fahrzeugboden zum Schalten der Carrera Weichen
** Ansteuerung der Fahrzeug LEDs (Fahrlicht, Bremslicht)
** Magnet-Winkelencoder am Leitkiel (AS5045; Optional, zur Messung der Leitkielstellung, Driftwinkel usw.)
** (Beschleunigungssensor nicht (mehr) verbaut)
* Kommunikation:
** RS232-Kommunikationsinterface über Aufsteckplatine (BT-Modul von Free2Move im transparenten RS232-Modus)
** Piezo-Piepser
* Prozessor:
** Freescale HCS12C96 (50MHz); 3.3V; 96k Flash (10k benutzt); 4k RAM (3k benutzt)
 
|}

Der Gyrosensor liefert einen '''Drehratenwert''' (skaliert in 70 MilliDegrees per Second; mdps) und wird zyklisch jede 1ms ausgelesen.

Zur '''Drehzahlmessung''' (und '''Entfernungsmessung''') wurde auf der hinteren Antriebsachse eine Scheibe angebracht, die pro Radumdrehung 8 Flankenwechsel liefert. Da wir momentan nur die High-Low-Flanken auswerten erhalten wir bei einem Radumfang von 70mm eine Auflösung von 17.5mm pro Reflexkoppler-Impuls. Der Impuls wird nicht nur gezählt, sondern der genaue Zeitpunkt wird zusätzlich per InputCapture-Einheit erfasst, um eine deutlich höhere zeitliche Auflösung zu erhalten und somit die Raddrehzahl auch bei "niedrigen" Drehzahlen sauber erfassen zu können. Im relevanten Drehzahlbereich von ca. 1000RPM..8000RPM kommt im Schnitt etwa alle 1..10ms ein Wheeltick (=17.5mm).

Die beiden Beschleunigungs- und Bremsmosfets werden mit einem Mosfet-Treiber angesteuert, da diese weniger Platz auf der sowieso knappen Platinenfläche einnimmt und auch die Dimensionierung der sonst notwendigen diskreten Mosfet-Beschaltung vereinfacht.

[[File:Uebersichtsplan_HW.png|450px|left|thumb|Übersichtsplan HW]]
Der verwendete HCS12-Prozessor von Freescale wurde gewählt, weil dieser aus anderen Projekten bereits vertraut war und die technischen Daten (Taktfrequenz, Speicher) dem Einsatz nicht im Wege standen, bzw. alles so ausgelegt wurde, dass die Ressourcen passen.

Versuche mit '''3-Achsen-Beschleunigungssensoren''' brachten keine befriedigenden Ergebnisse, weshalb diese (auch aus Platzgründen) nicht verbaut wurden. Das Nutzsignal war in der gleichen Größenordnung wie das Rauschen, woraus sich keine sinnvoll verwertbaren Daten ableiten ließen. Ursache dafür waren vermutlich die starken Motor- und Fahrbahnvibrationen, die sich trotz mechanischer Entkopplung (Moosgummi) nicht ausreichend verbesserten.

Der '''Leitkielwinkelsensor''' wurde als Vorhalt eingeplant, um den fahrdynamischen Grenzbereich (wenn das Fahrzeug langsam in den Drift übergeht) besser ausmessen zu können. Der Leitkiel ist eine Führungsschiene im Unterboden des Fahrzeugs, die im Schlitz in der Fahrbahn entlangläuft und zur Spurführung dient.
Hierzu wird die Leitkielstellung relativ zum Fahrzeug gemessen. Bei Kurveneinfahrten dreht sich der Leitkiel relativ zum Fahrzeug ein Stück zur Seite. Übersteigt dieser Winkel einen bestimmten Wert, so kann man daran ein Driften des Fahrzeugs ablesen. Durch Montage eines kleinen Magneten auf dem Leitkiel läßt sich dessen Winkel bzw. Verdrehung relativ zum feststehenden MagnetWinkelencoder messen.
Der magnetische Winkelauflösung beträgt 12Bit, was ca. 0.1° entspricht - also weit genauer als hier nötig wäre. Alle 4ms wird ein neuer Messwert geliefert.
Derzeit messen wir den Leitkielwinkel zwar, verwerten die Daten aber nicht. Grund: Da die Montage relativ aufwendig ist (modifizierter Leitkiel; Befestigungsmöglichkeiten), wollten wir nur dann auf die Daten zurückgreifen, falls eine ausreichend schnelle Fahrt nicht ohne diesen möglich wäre.

Das Einlesen der Carrera Digitaldaten auf den Schienen ist dazu gedacht, um das Fahrzeug vom Benutzer parametrieren und manuell fahren zu können. Denkbar wäre es z.B. die Fahrgeschwindigkeit künstlich einzuschränken oder den Fahrbeginn vom Benutzer per Handregler starten zu können.
Voraussetzung dafür ist ein schnelles und ungepuffertes Einlesen der Schienenspannung. Die Schiene führt bei Digitalbahnen auf der einen Spur Gnd und auf der Anderen einen Pegel von 12-18V je nach Trafo. Zur Kommunikation von der Carrera-Steuereinheit zum Fahrzeug ist der Gleichspannung ein PWM-Signal überlagert. Eine Datenübertragung vom Fahrzeug zur Steuereinheit ist nicht vorgesehen.
Das ungepufferte Einlesen der Schienenspannung steht in entgegengesetzter Anforderung zu einer stabilen Spannungsversorgung für die Elektronik. Durch Lücken in der Schiene ("Weichen") kommt es zu Aussetzern von ein paar wenigen Zentimetern bzw. wenigen hundert Millisekunden, die von einem Stützelko überbrückt werden müssen. Die überlagerten Kommunikationssignale sind deshalb (per Diode) von der internen Versorgung entkoppelt.

Grundsätzlich unterstützt das GCP auch Analogbahnen mit einer konstanten Spannungsversorgung (=> "Handregler per Klebeband auf Vollgas fixieren")

Die '''IR-Sendediode''' im Fahrzeugboden erlaubt bewusst eingeleitete Spurwechsel, um z.B. jederzeit auf der Ideallinie fahren zu können. Um die anderen Fahrzeug nicht abzuschießen, würde das aber praktisch auch mehr Rundumsicht benötigen (=> "Abstandssensoren"). Automatische Spurwechsel sind derzeit aber noch nicht implementiert.

Um den Reflexkoppler einzusparen, und so den Nachbau zu erleichtern, bzw. zu verbilligen, haben wir auch die Drehzahl ohne Reflexkoppler getestet ("Drehzahlmessung per Gegen-EMK"). Dabei wird ausgenutzt, dass die im Motor induzierte Gegenspannung proportional zu seiner Drehzahl ansteigt. Misst man diese "elektromotorische Kraft" zu einem Zeitpunkt in der der Motor nicht bestromt wird ("PWM-Aus"-Phase), so kann man eine Aussage über seine Drehzahl treffen. Praktisch funktioniert dies auch prinzipiell, allerdings war die Messung nicht so genau wie die Drehzahlmessung per Reflexkoppler, was dann den Regler (bzw. unsere Reglerparameter) überforderte. Das Fahrzeug fuhr deutlich "unrunder". Das Motorgeräusch war schrecklich. Deshalb haben wir diese Option bisher auch noch nicht weiter vertieft, obwohl da noch Verbesserungsotential stecken dürfte.

<div style="clear:both"></div>

== Software ==

Neben den obligatorischen Komponenten wie Scheduler und Lowlevel-Treibern (InputCapture, Pwm, Adc, Spi) besteht der Kern der Gcp-Software aus den beiden Komponenten Kommunikationsmodul (ApplComm) und allem, was mit der Bestimmung Fahrzeugposition und Ansteuerung des Motors zusammenhängt (ApplLap).

=== ApplLap: Sektorerkennung, Positionsbestimmung und SollDrehzahlberechnung ===

[[File:Sourcecode.png|61px|thumb|left|ApplLap.c|link=http://www.hierlinksetzen.de]]
Die oben beschriebenen Konzepte und Ideen sind im Modul ApplLap implementiert. Der zentrale 1ms-Task, in dem alle zyklisch anfallenden Arbeiten ausgeführt werden, verwaltet die einzelnen Teilkomponenten, wie Sektorerkennung weiß, Sektorerkennung schwarz und SollDrehzahlberechnung.
Die Teilkomponente Positionsbestimmung ist weniger zeitkritisch, aber relativ rechenzeitintensiv, weshalb diese nicht wiederkehrend alle 1ms gerechnet wird, sondern nur dann, wenn ein neuer potentieller Syncpunkt anfällt (also ein neuer schwarzer Sektor geliefert wird). Die Ausführung findet im IdleTask statt, der immer dann (weiter)gerechnet wird, wenn der 1ms-Task seine Arbeit erledigt hat. Die Positionsbestimmung wird somit ständig von den zyklischen 1ms-Aufgaben unterbrochen. Es ist mit dem aktuellen Stand der Software so, dass der 1ms-Task maximal 820µs Laufzeit verbraucht und für den Idletask pro 1ms nur (minimal) 180µs Rechenzeit übrig bleiben. Letztendlich liefert die Positionsbestimmung dann aber nach spätestens 30ms einen neuen Syncpunkt. (Der zwischenzeitlich verfahrene Weg wird natürlich berücksichtigt).

=== ApplComm: Kommunikation zum PC ===

[[File:Sourcecode.png|61px|thumb|left|ApplComm.c|link=http://www.hierlinksetzen.de]]
Das Kommunikationsmodul implementiert ein kleines Protokoll zur Datenübertragung zum PC. Hierüber werden in verschiedenen Modi (die vom PC vorgegeben werden) folgende Daten vom Fahrzeug an den PC gesendet:
* '''LiveMeasure-Daten''': interne Variablen zur (grafischen) Echtzeitanalyse, wie z.B. MomentanDrehzahl, SollDrehzahl, aktueller GyroZ-Wert, Debugvariablen usw.; bis zu 6 Parameter werden (typ.) alle 50ms übertragen.
* '''Fastlog''': Echtzeitübertragung aller physikalischen Eingangsgrößen(!)
* '''weiße und schwarze Sektordaten''': Länge, Wegpunkt, Winkel, Lage, Bandmitte zur späteren automatischen oder händischen Auswertung.
* SyncTelegramme: Wegpunkt der Synchronisierung und um wieviele Wheelticks ("cm") die errechnete Position korrigiert werden musste
* Diagnosedaten, wie z.B. Prozessorauslastung im 1ms-Task/Idle-Task, um Ressourcenprobleme erkennen zu können.

== PC-Software zur Auswertung und Simulation ==

Die empfangenen '''LiveMeasure'''-Daten werden von einer dafür entwickelten PC-Software in Echtzeit in einen Graphen eingetragen und helfen somit bei der visuellen Bewertung der Fahrzeugsituation. Hilfreich ist dies z.B. beim Aufspüren von Fahrzeugdrifts am Kurvenein- oder ausgang (GyroZ-Sprung/Schwinger im Graphen) oder bei der Bewertung der Reglerparameter ("Istdrehzahl schwingt über"). Da hierbei nicht alle Messwerte übertragen werden können, reicht diese Analysemethode nur für erste grobe Einschätzungen.

Daneben gibt es aber viele Situationen, die schwieriger zu bewerten sind. Zum einen, weil nicht alle, zur Analyse nötigen Daten, vorliegen (50ms Aktualisierungsrate reicht oft nicht aus), zum anderen, weil die 6 Livemeasure-Kanäle nicht ausreichen.

Die Frage "Wieso wurde die Sektorgrenze nicht gesehen" läßt sich nicht nur durch Betrachten des GyroZ-Verlaufes beantworten, sondern es ist notwendig den Algorithmus live zu beobachten. Da sich das Fahrzeug aber bewegt und sich damit eine Onboard-Debugmöglichkeit ausschließt, mussten die Daten zur späteren Auswertung aufgezeichnet werden. Hierzu nimmt der PC die in Echtzeit / live gesendeten physikalischen Messgrößen entgegen (Betriebsart "'''Fastlog'''" und liegt diese in einem Logfile ab. Dadurch können auch sehr lange Messfahrten problemlos aufgezeichnet werden.
Am Ende werden die phyikalischen Eingangsgrößen am PC genauso nachgerechnet, wie diese auch im Fahrzeug berechnet wurden. So ist es möglich zu beliebigen Zeitpunkten und an beliebigen Stellen das Verhalten des Algorithmus zu betrachten/debuggen und die grafische Ausgabe zu analysieren.
Die PC-Software enthält hierzu eine Komponente (Targetcode.cs), in dem der (relevante) Microcontrollercode fast 1:1 identisch nachgerechnet wird. Die Dateien lassen sich relativ einfach per Diff-Tool auf gleichem Stand halten.

Um algorithmische Probleme zu lösen, die keinen Echtzeitbezug benötigen, reichen die Daten der Sektortelegramme aus.
Für die heuristische Positionsbestimmung z.B. ist eine Simulation umgesetzt, die als Eingangsdaten, rein die gelieferten Sektordaten benötigt. In der Ausgabe der Simulation lassen sich somit einfach die Ähnlichkeitsmatrix, Häufigkeitsverteilung oder gewichtete relative Wahrscheinlichkeit realer Fahrzeugsituationen analysieren.

[[File:Vorschaubild-Video-(Simulation-Sektorerkennung).png|200px|right|Simulation Sektorerkennung|link=http://youtu.be/bM2tu5I-Dqs?hd=1]]
Auch das Bestimmen der Parameter für die Sektorerkennung (weißer Algorithmus) ließ sich sehr anschaulich über eine PC-Simulation lösen. Hier kann in Echtzeit grafisch beobachtet werden, welchen Einfluss das Verstellen der Parameter auf die Wahl der Sektorgrenzen hat (siehe [http://youtu.be/bM2tu5I-Dqs?hd=1 Video]). So ist schnell überprüfbar, ob die Sektordaten sinnvoll die tatsächliche Kurvenform (GyroZ-Verlauf) wiedergeben können.

'''Fazit''': Ohne die umfangreichen Simulationsmöglichkeit wäre es unmöglich gewesen auch nur ansatzweise ein autonom fahrendes Fahrzeug zu bauen. Der Einsatz des Prozessordebuggers konnte auf die Fälle beschränkt werden, an denen (einfache) elektrische/physikalische Probleme auftaten (z.B. Probleme beim Einlesen der Reflexkoppler-Daten aufgrund von Prellen, bzw. der elektrische Signalform und bei Implementationsfehlern im Kommunikationsprotokoll...). Die restlichen, schwierigeren algorithmischen Implementationsprobleme ließen sich komfortabel in der Simulation austesten.

== Probleme bei Planung und Durchführung ==

Schneller als erwartet und ohne ernste Probleme ging die Entwicklung der Hardware inkl. Grundsoftware von statten. Schon nach wenigen Wochen(enden) hatten wir ein erstes fahrfähiges Muster in der Hand. Da dieses bereits dank Drehzahlerfassung mit konstanter Drehzahl fahren konnte und nicht mit konster PWM fahren musste (das führt in Kurven dazu, dass die Geschwindigkeit aufgrund erhöhter Reibung minimal einbricht), war das GCP bereits geringfügig schneller als das original Carrera Ghostcar. Eigentlich war unser erstes Projektziel damit schon erreicht.

Danach ging es an die Erfassung des Streckenmodells ("weißer Algorithmus"). Wir konnten ohne PC-Simulation und ohne Livedatenerfassung aus dem Fahrzeug nicht zu brauchbaren Parametern für den weißen Algorithmus gelangen. Also musste eine umfangreiche Log-/Debug-Infrastruktur aufgebaut werden. Die Ideen zur Verbesserung der weißen Sektordaten bzw. "Erfindung" des schwarzen Algorithmus ließen etwas auf sich warten, waren aber einige Wochen und (Matlab)Simulationen später, umsetzungsreif und implementierbar.
Das größte und am meisten unterschätzte Problem war jedoch die eigentliche Positionsbestimmung. Nachdem bereits gute und reproduzierbare Sektordaten vorlagen, waren wir zunächst guter Dinge, dass dies nur noch ein kleiner Schritt sein müsste.
Wir waren bis dahin davon ausgegangen, dass wir mit einer Referenzfahrt zur Aufzeichnung der Sektordaten beginnen könnten, die dann in die Ghostcarfahrt übergehen würde. Wir konnten keine Kriterien finden, die sauber bei jedem denkbaren Streckenverlauf ein Rundenende erkennen konnte. (Theoretisch kann man dies wohl beweisen/erkennen, wenn man bereits zwei(!) vollständige Runden zurückgelegt hat - praktisch ist uns das algorithmisch aber nicht zuverlässig gelungen).

[[File:Vorschaubild-Video-(Fahrt).png|200px|right|Ghostcar-Fahrt|link=http://youtu.be/k1GCKp2Ms3Q]]
Letztendlich vergingen ungefähr 8 Monate bis das Konzept der Positionsbestimmung in der jetztigen Form feststand. Damit waren alle Voraussetzungen für eine autonome Fahrt geschaffen. Es war ein spannender Augenblick, als das Auto zum ersten Mal auf Geraden beschleunigte und vor Kurven rechtzeitig bremste. (Siehe [http://youtu.be/k1GCKp2Ms3Q Video]) Eigentlich wollten wir vorher noch das Fahrzeug gegen Einschläge polstern, was dann aber doch irgendwie vergessen wurde...

Auch wenn zum aktuellen Projektstand das Gcp noch keine Konkurrenz für einen trainierten Fahrer ist, so fährt es Anfängern doch davon. Es ist also noch Potential nach oben vorhanden, vor allem, wenn man Drifts zur Verbesserung der Rundenzeit zuläßt. Sofern man überhaupt davon ausgeht, dass damit die Rundenzeit tatsächlich schneller wird - was noch zu beweisen wäre...

== Verbesserungsideen ==

*'''Alles was die Rundenzeit verbessert'''
** Auswertung des Leitkielwinkels zur Erkennung von fahrdynamischen Grenzbereichen; "Kontrolliertes driften"
** Durch Überschwinger am Kurvenende bei höherer Geschwindigkeit werden zusätzliche schwarze Sektoren erzeugt, die bei langsamerer Fahrt nicht auftreten und deswegen zu Syncproblemen führen. Diese zusätzlichen Sektoren könnten ausgeblendet/unterdrückt werden (Modifikation Schwarzer Algorithmus) und somit eine höhere Grundgeschwindigkeit gefahren werden. (Derzeit fahren wir noch nicht an der physikalischen Haftgrenze, sondern an der "Reproduzierbarkeitsgrenze" der schwarzen Sektoren).

* '''Alles was die Fahrt besser macht'''
** Beschleunigen nicht nach Streckenmodell, sondern nur nach aktuellem GyroZ. Dadurch wird der Beschleunigungspunkt nicht "verpasst" und auch nicht zu früh begonnen zu beschleunigen.
** Dynamische Bandhöhe: Eine höhere Auflösung der gewählten Bandhöhe bei kleinen GyroZ-Werten würde zu weniger gemeldeten weißen Sektoren führen und damit weniger Speicherplatz bzw. Listenplätze belegen. Würden die angelegten Bänder um den GyroZ-Wert nur im Bereich um GyroZ -1000..+1000 hoch aufgelöst werden, weil genau in diesem Bereich hohe Geschwindigkeiten gefahren werden (können), so müsste man die Momentangeschwindigkeit nicht vom (betragsmäßig) größten GyroZ-Wert in diesem (hohen) Band abhängig machen => ebenfalls schnellere Fahrt möglich.
** Die Bremspunktbestimmung schaut momentan zwei Sektoren in die Zukunft. Würden zwei sehr kurze, aber schnelle Sektoren anstehen, aber ein dritter sehr enger Sektor folgen, könnte dieser übersehen werden und das Bremsen zu spät eingeleitet werden. (Unklar, ob eine solche Strecke mit Carreraschienen praktisch überhaupt gebaut werden kann).
** "GapSektoren": Als weiteres Kriterium für die Positionsbestimmung könnte die Lage der "Schienenlücken" (Unterbrechungen der Stromleiter durch Weichen, Kreuzungen) dienen. Erkennung durch Schienenspannungsmessung; Vorteil: ortsfest; Nachteil: Nicht auf allen Bahnen vorhanden; Ausgiebige Tests zeigten sehr gute Eignung

* '''Alles was das Fahren interessanter machen könnte'''
** Abstandssensoren, um Spurwechsel überhaupt erst zur ermöglichen (kein Abschießen von nebeneinander fahrenden Autos) und um dicht vor oder hinter einem anderen Fahrzeug fahren zu können.
** Einstellbare Geschwindigkeit des Ghostcars, um sich auf verschieden starke Gegner abstimmen zu können
** Tuningparameter vom Benutzer einstellbar machen. Dadurch könnte dieser sein Fahrzeug auf seine Strecke abstimmen. Dies könnten z.B. folgende Parameter sein:
*** '''maximale Beschleunigung''' (bessere Reifen, besserer Grip => höhere Beschleunigung möglich). Eine zu hoch eingestellte Beschleunigung würde zu durchdrehenden Rädern führen und somit Rundenzeit kosten.
*** Variation des ermittelten Bremspunkts: Wie knapp soll wirklich gebremst werden (Sicherheitsreserve vs. Risiko)
*** '''Kennlinie'''; Abhängigkeit der Geschwindigkeit vom Kurvenradius (hohes Optimierungspotential; stark Strecken- und Fahrzeugabhängig)
** Ausnutzung der Weichen, um Wegstrecke zu sparen
** und noch viele weitere Ideen...

== Sonstiges ==

Aufgrund des begrenzten Umfangs dieses Artikels, müssen leider viele Punkte offen bleiben oder werden nur in einem kurzen Nebensatz angerissen. Sollten noch Fragen auftauchen, bitte melden.

GCP ist ein Freizeitprojekt von and_ref und galoscha.
Eine kommerzielle Verwertung ist nicht gestattet. Bei entsprechendem Interesse bitte anfragen. :-)

'''Kontakt''': André; and_ref (at) canathome.de

[[Kategorie:Wettbewerb]]

Datei:Signalflussdiagramm Sektorerkennung.png

2013-03-06T20:36:48Z

And ref:

Datei:Vorschaubild-Video-(Fahrt).png

2013-03-06T20:35:02Z

And ref:

Datei:Vorschaubild-Video-(Simulation-Sektorerkennung).png

2013-03-06T20:31:52Z

And ref:

Datei:Sourcecode.png

2013-03-06T20:31:21Z

And ref:

Datei:Uebersichtsplan HW.png

2013-03-06T20:31:00Z

And ref:

Datei:Layout-bottom Gcp.png

2013-03-06T20:30:38Z

And ref:

Datei:Layout-top Gcp.png

2013-03-06T20:30:18Z

And ref:

Datei:Schaltplan Gcp.png

2013-03-06T20:29:55Z

And ref:

Datei:Signalflussdiagramm Drehzahlregler.png

2013-03-06T20:27:57Z

And ref:

Datei:Bremsvorgang.png

2013-03-06T20:27:36Z

And ref:

Datei:Kennlinie GyroZ2Rpm.png

2013-03-06T20:27:21Z

And ref:

Datei:Signalflussdiagramm Fahrprofil.png

2013-03-06T20:27:07Z

And ref:

Datei:Heuristik2.png

2013-03-06T20:26:51Z

And ref:

Datei:Heuristik1.png

2013-03-06T20:26:39Z

And ref:

Datei:Signalflussdiagramm Positionsbestimmung.png

2013-03-06T20:26:25Z

And ref:

Datei:Sektorerkennung (schwarz).png

2013-03-06T20:26:04Z

And ref:

Datei:Sektorerkennung (weiss).png

2013-03-06T20:25:46Z

And ref:

Datei:Streckenverlauf Gcp1Short.jpg

2013-03-06T20:25:29Z

And ref:

Datei:Signalflussdiagramm.png

2013-03-06T20:24:34Z

And ref:

Datei:Positionsermittlung (animiert)-Vorschau.gif

2013-03-06T20:24:13Z

And ref:

Datei:Streckenmodell (animiert) Vorschau.gif

2013-03-06T20:23:30Z

And ref:

Datei:Ghostcar Reflexkoppler.jpg

2013-03-06T20:22:53Z

And ref:

Datei:Ghostcar.jpg

2013-03-06T20:22:34Z

And ref:

Datei:Ghostcar 3er.jpg

2013-03-06T20:22:07Z

And ref:

GhostCarProjekt

2013-03-03T13:12:40Z

And ref: Die Seite wurde neu angelegt: „''von and_ref'' {{Wettbewerb Header}} '''<big>GCP</big>''' - das '''GhostCarProjekt'''... ... steht als Projekttitel für die Realisierung eines autonom fahren…“

''von and_ref''

{{Wettbewerb Header}}

'''<big>GCP</big>''' - das '''GhostCarProjekt'''...

... steht als Projekttitel für die Realisierung eines autonom fahrenden Fahrzeugs auf einer spurgebundenen Spielzeugrennbahn. Es soll ein Auto entwickelt werden, das auf einer Carrerabahn möglichst schnelle Rundenzeiten fährt. Dabei sind Eingriffe in die Strecke oder Steuerbefehle von außen tabu.

<big>Details folgen in Kürze...</big>

Elektronischer Zauberwuerfel

2008-07-27T13:53:33Z

And ref: Links zur besseren Sichtbarkeit hervorgehoben

Der "Elektronische Zauberwürfel" ist die elektronische Variante des aus den 80er-Jahren bekannten Rubik's Magic Zauberwürfels. Es entsteht zunächst eine Studie/Prototyp, die zeigen soll,  ob die Spielidee des mechanischen Zauberwürfels auf eine elektronische Variante übertragbar ist und durch zusätzliche Features sinnvoll ergänzt werden kann. 

[[Image:EZW Rubiks3x3x3.jpg|thumb|80px|Rubiks Zauberwürfel]] 

 __TOC__

 

== Idee und Motivation ==

Die gängigen Rubiks Zauberwürfel haben 3x3x3 Steine. Neben dem Rubiks Revenge (4x4x4) und dem Rubiks Professor (5x5x5) gibt es keine käuflichen größeren Zauberwürfel - vermutlich aus mechanischen Gründen. Die virtuellen Würfel (PC-Software) lassen sich nicht in die Hand nehmen und auf natürliche Weise begreifen und lösen. Daher dachte ich zunächst einen 8x8x8 Würfel zu bauen, der ähnlich wie ein mechanischer Zauberwürfel lösbar sein sollte (In die Hand nehmen, drehen und die Farben suchen...). Nach kurzer Überlegung, wie viele Lampen und Taster ich dazu brauchen würde, habe ich die Idee gaaanz schnell aufgegeben und mich auf einen 3x3x3er konzentriert. (8x8x8: 512Felder zu je 6LEDs -> 3000LEDs)

Der Reiz den mechanischen Zauberwürfel überhaupt lösen zu können, verfliegt nach ein paar Tagen und es stellt sich die Frage: "Wie ''schnell'' kann ich den Zauberwürfel lösen?". Aus dem anfänglichen neugierigen Spiel wird eine technische Sportart, die auf folgende Punkte Wert legt:

* zeiteffizientes und/oder zugeffizientes Lösungsverfahren (Lösen mit möglichst wenigen Drehungen)
* definiertes Verdrehen vor dem eigentlichen Lösungsvorgang
* Zeitmessung des Lösungsvorgangs
* Protokollierung des Lernfortschritts (Lösungszeiten aufzeichnen und auswerten)

Der Elektronische Zauberwürfel soll diese Dinge vereinfachen.

 

== Features ==

Folgende Funktionen sollen umgesetzt werden:

* '''Auto-Scramble''' (Verdrehen des Zauberwürfels auf Knopfdruck)
* '''Automatische Zeitmessung''' (Competition Mode)
** Die LEDs des verdrehten Würfels werden erst nach Tastendruck freigegeben. Damit beginnt die Einprägungsphase.
** Nach Ablauf der Einprägungsphase (typisch 15s) beginnt die eigentliche Lösungszeit zu laufen. Dies kann vorgezogen werden, indem schon vor Ablauf der Einprägungsphase eine Taste gedrückt wird.
* Abspeichern der erzielten Zeiten zur '''Auswertung am PC'''
* mechanisches Drehen entfällt. Dadurch soll sich die Lösungszeit verringern lassen, da keine "Verklemmer" die Zeit beeinflussen. (Muss noch ausprobiert werden, ob nicht gerade das dann letztendlich den Reiz ausmacht)
* '''Tutorialfunktion''' zum Erlernen von Zugfolgen; schnelles Rücksetzen auf abgespeicherte Ausgangspositionen (Rückdrehen oder langwieriges Wiederherstellen der Position entfällt)
* '''Lösungsvorschläge'''; Würfel macht Vorschlag, wie er aus aktueller Situation gelöst werden kann (das dürfte die anspruchvollste Aufgabe sein)

 

== Mechanik ==

Beim elektronischen Zauberwürfel gibt es keine beweglichen Teile. Jede der sechs Seiten des Würfels besteht aus einem feststehenden 3x3-Feld aus LEDs. An allen Kanten sind Taster, die die ''gedachten'' beweglichen Teile in der gewünschten Drehrichtung weiterdrehen, d.h. die angezeigten Felder ändern ihre Farben. Übertragen auf einen mechanischen Würfel, würde sich diese Ebene bei einem Tastendruck dann um 90° in die gedrückte Richtung drehen.

 ''Die folgenden Bilder zeigen den bereits gefrästen, aber noch nicht verleimten Holzrahmen.''''' '''

In der Mitte jeder Seite ist das 3x3-LED-Feld. Jedes Feld besteht aus 6 farbigen EinzelLEDs, von denen immer nur eine leuchtet. Neben jeder Spalte und Zeile sitzen Taster. Pro Seite werden somit 12 Taster verbaut. 

{| width="100%" cellspacing="20" cellpadding="1" border="0"
|-
| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Holzrahmen4.jpg|thumb|150px|geplante Würfeloberseite]] Damit die Außenkante des Würfels höher ist als die verwendeten Taster (Schurter LSH SMD-Taster; Reichelt: TASTER 9315; Bauhöhe 5mm; Taster sollen nicht überstehen), müssen die Platinen 8mm tief liegen. -> Außenprofiltiefe der Kante: 8mm. Die Platinen sind mit einem umlaufenden Rand von 6mm entworfen. Damit ergibt sich die gewählte Profilform der Kantenteile.

 

 

| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Holzrahmen3.jpg|thumb|150px|Holzrahmen]] An einem Holzrahmen werden die Seitenplatinen befestigt. Kantenlänge des Holzwürfels: 10cm (möglicherweise etwas zu groß?!). Auf diesem Foto fehlen noch die Ausfräsungen der langen Kantenteile, damit die Platine (hier: links vorne) plan aufliegt und keine Aussparungen braucht)

|-
| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Holzrahmen1.jpg|thumb|150px|Einzelteile des Holzrahmens]] Der Holzrahmen besteht aus zwei verschiedenen Profilteilen:

* 4x Kantenteil -lang- (98mm)
* 8x Kantenteil -kurz- (70mm)

| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Holzrahmen2.jpg|thumb|150px|gefräste Kantenteile]] Die Profile haben die Kantenmaße: 20x20mm.

|-
| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Profilschnittbogen.png|thumb|150px|Profilschnittbogen]] Um mir die Sache vor dem Fräsen besser vorstellen zu können, habe ich mir die Kantenteile aus Papier gebastelt. :-)

| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Profilquerschnitt.png|thumb|150px|Profilquerschnitt]] Fräszeichnung

|}

 

== Elektronik ==

=== Konzept mit ''dimmbaren'' RGB-LEDs (verworfen) ===

Zunächst habe ich versucht die Anzahl der LEDs gering zu halten, und für jedes Feld eine RGB-TrueColor-LED vorgesehen. Der Vorteil dabei ist, es ist nur eine LED zu bestücken und es müssen nur 3 Ausgangskanäle (statt 6) verwendet werden - aber diese müssen dann auch dimmbar sein. Und da fing das Problem an...

Kurze Überschlagsrechnung für 162 dimmbare Kanäle (= 6 Seiten x 9 Felder x 3 LEDs) über 8Bit-SPI-Schieberegister (andere Ansteuermöglichkeit sehe ich nicht): [[Image:EZW PwmKonzept.png|thumb|300px|PWM-Konzept zur Ermittlung des zu versendenden Bytes aus der Tabelle der Helligkeitswerte]]

* '''162 Kanäle''' verteilt auf 6 Platinen (nur "ganze" Schieberegister pro Platine) -> 27Kanäle pro Würfelseite/Platine -> 4 Schieberegister pro Seite -> Summe: '''24 Schieberegister''' für den gesamten Würfel (wären theoretisch dann sogar 192 dimmbare Kanäle)
* damit die LEDs nicht flimmern sollten '''200Hz Wiederholrate''' gewählt werden (= 5ms Periodendauer).
* um vernünftige Farben mischen zu können, müssen diese mit '''10% Helligkeitsauflösung''' (lineare, zeitliche Auflösung der Periode; Wert 10% experimentell ermittelt) ansteuerbar sein.
* somit muss jede LED alle 500µs aktualisiert werden (5ms/10Steps=500µs). Bei 24 in Reihe geschalteten Schieberegistern, bleibt somit 20.8µs pro Schieberegister Zeit. (das entspricht also auch der Zeit pro rauszuschickendem Byte).
* -> SPI-Baudrate: 500µs/24Byte -> 2.6µs/Bit -> '''384kBit/s''' (das wäre noch problemlos machbar) 

'''Ergebnis''': D.h. es bleibt dem System genau 20µs, um zu berechnen, welches Byte als nächstes per SPI zu verschicken ist. In dieser Zeit müssen die Helligkeitswerte von 8LEDs in eine binäre Information umgesetzt werden (z.B. LED0: 80%; LED1: 100%...). Die hierfür entwickelte Testroutine (Lookuptable, zur Erhöhung der Ausgabegeschwindigkeit...) benögte dafür 45µs auf dem Zielsystem (HCS12C32@50MHz) und ist damit '''um den Faktor 2.5 zu langsam'''. Nebenbei sollte ja noch andere Dinge erledigt werden, wie z.B. Züge berechnen usw. '''''Damit ist das Konzept erst mal auf Eis gelegt.'''''

 

=== Konzept mit sechs Einzel-LEDs pro Feld ===

Nachdem das DimmKonzept aus Timinggründen nicht umsetzbar war, plante ich die Umsetzung von 6 Einzel-LEDs pro Feld. Jede Seite hat 9x6 EinzelLEDs -> pro Würfel sind das dann 324 zu verbauende LEDs, die über Schieberegister angesteuert werden und statisch leuchten sollen.

Elektrische Features:

* statische Ansteuerung der LEDs (kein Dimmen); LED Typ: Osram SmartLED 0603, da ausreichende Helligkeit bei kleinem Strom (1..5mA)
* Verwendung von 7 handelsüblichen 8Bit-Schieberegistern HC595 pro Seite (keine separate Treiberstufen oder spezielle LED-Treiberbausteine notwendig); der HC595 erlaubt an seinem EnableEingang durch eine PWM-Ansteuerung auch das Dimmen der angeschlossenen LEDs - allerdings alle auf einmal, so dass hiermit die Gesamthelligkeit des Würfels verringert werden kann.
* die 72 Taster werden ebenfalls über SPI-Schieberegister eingelesen (zeitgleich mit der Ausgabe der LED-Daten); HC165
* Piezopiepser zum Erzeugen von Hinweistönen
* es soll nur 1 Layout für alle 6 Seiten geben
* Kabelverbindung zwischen den 6 Seiten über Verbindung zur "Vorgängerseite" und "Nachfolgerseite". Damit ergibt sich eine Kette über die 6 Seiten.
* Stromversorgung über Kabel; Anbindung von Akkus (über Step-up/-down-Konverter) bereits über Lötpads vorgesehen.
* Datenanbindung an PC über RS232-Schnittstelle (Zeitmessung; Darstellung auf PC)
* Eeprom zum Abspeichern der erzielten Zeiten 
* ausgesuchter Prozessor: HCS12C32 @50MHz, da Gehäuse mit LQFP48 relativ klein ist (verglichen mit anderen HCS12-Derivaten) und hierfür bereits eine Entwicklungsumgebung und ein Referenzdesign vorlag; Die Realisierung ist natürlich ebenso mit anderen Controllern möglich. 

 

=== Schaltplan/Layout ===

{| width="600" cellspacing="1" cellpadding="1" border="0"
|-
| [[Image:EZW Schematic.PNG|thumb|left|150px|Schaltplan]]
| [[Image:EZW Layout top.PNG|thumb|left|150px|Layout (top)]]
| [[Image:EZW Layout bot.png|thumb|left|150px|Layout (bottom)]]
|}

 

{| width="80%" cellspacing="1" cellpadding="3" border="2"
|-
| bgcolor="#f7f7f7" |
== Technische Daten ==

'''Prozessor''': Freescale HCS12C32 (50MHz); 5V; 32k Flash (12k benutzt); 2k RAM (600Bytes benutzt) '''Schieberegister''': 42x 74HC595 zur LED-Ansteuerung; 12x 74HC165 zum Einlesen der Taster '''LEDs''': Gesamt: 324 Stück (54Stück von jeder Farbe: weiß, blau, rot, orange, grün, gelb); Gehäuse: 0603 '''Taster''': 72 Stück (12 auf jeder Seite) '''Gesamtstromaufnahme''': 50mA (LEDs auf 1% gedimmt)... 320mA (LEDs auf 100% gedimmt) bei 5V 

|}

 

 

 

== Fertige Hardware ==

Fotos der Elektronik

{| width="100%" cellspacing="20" cellpadding="1" border="0"
|-
| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Platine LED-Seite.jpg|thumb|150px|Platine: LED-Seite]] Jede Seite des Würfels besteht aus 6 dieser Platinen. Die Außenseite ist mit Tastern und LEDs bestückt...

| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Platine Prozessorseite.jpg|thumb|150px|Platine: Prozessor-Seite]] ... auf der Innenseite sitzt die Elektronik. Nur eine der sechs Platinen ist mit einem eigenen Prozessor ausgestattet - alle anderen tragen nur die Schieberegister.

|-
| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Gesamtansicht1.jpg|thumb|150px|Gesamtansicht]] So sieht der Würfel aus, wenn er zusammengebaut ist.

| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Gesamtansicht2.jpg|thumb|150px|Gesamtansicht]]

 

|}

 

=== Ausblick/Verbesserungsideen ===

Statt der Verwendung von RGB-LEDs könnten auch 6 Einzel-LEDs verbaut werden, die allerdings nicht gedimmt werden, sondern mit verschiedenen zuschaltbaren Vorwiderständen angesteuert werden. Vorteil: LED in einem Gehäuse; kein "Versatz" bei unterschiedlichen Farben; zu prüfen, ob RGB-LED auch ohne Streuscheibe verwendet werden kann; sind Farben noch als solche erkennbar oder nur die 3 LED-Grundfarben? Als Tasteralternative könnten eventuell auch Sensortasten in Frage kommen?! QT1106 ([http://www.qprox.com/assets/Downloadablefile/QT1106_-8IR0.07-16262.pdf '''Datenblatt''']) (3,55€ bei Farnell); evtl. zwischen den LEDs angeordnet... 

 

== Mikrocontroller-Software/Firmware ==

Die Software besteht aus den Modulen/Teilen für:

* RS232-Kommunikation (zum PC)
* SPI-Kommunikation (zu Tastern und LEDs) 
* Menü- und Ausgabefunktionen des Würfels (Set/Restore waypoint; History; Mischen; Prüfen ob Würfel gelöst ist; Animation beim Drehen; ShowCube)
* Funktionen zum Drehen des Würfels (L, R, U, D, F, B); "L" bedeutet z.B., dass die linke Seite des Würfels im Uhrzeigersinn gedreht werden soll; 
** Welche Steine werden durch die Drehbewegung an welche Position gebracht? Um den Überblick zu behalten, helfen die unten aufgeführten Einteilungen/Nummerierungen der Steine/Seiten/Stickers. 

{| width="600" cellspacing="1" cellpadding="1" border="0"
|-
| [[Image:EZW Cube AufteilungFelder 3d.png|thumb|left|400px|Anordnung der Felder (oben, vorne, rechts); (unten, hinten, links)]]
| [[Image:EZW Cube AufteilungFelder.png|thumb|left|200px]]
|}

 

Zusammengehalten wird die Software von einem Scheduler, der einen 10ms-Task und einen 100ms-Task zyklisch bedient. Der 100ms-Task wird als 500ms-Task benutzt (nur jeden 5.Durchgang ausführen), um folgende Aufgaben abwechselnd auszuführen: 

* aktuelle Konstellation (wie ist der Würfel aktuell angeordnet; alle Stickerfarben) zum PC senden 
* Zustand aller Taster zum PC senden 
* Im CompetitionMode die aktuell laufende Lösungszeit an PC senden (Zeitmessung findet ja im Würfel selbst statt). 

Der 10ms-Task erledigt folgende Aufgaben: 

* Einlesen und Entprellen der Taster 
* "Umordnen" des Würfels in Folge der erkannten Tastendrücke (das erfordert relativ viel Aufwand, um die ganzen Sticker auf die neue Position zu "kleben"; kann durch Verwendung von Const-Arrays und generischen Funktionen sicher noch deutlich optimiert werden) 
* Menübehandlung (Brightness +/-; StartCompetition; Scramble; AnimationMode on/off; Undo/Redo; Set/Restore Waypoint; ResetCube) 
* Auswerten der vom PC empfangenen Kommandos (Grundhelligkeit; vom PC ausgelöste Drehbewegung...) 
* Animation der Drehbewegung/Drehrichtungsanzeige (abschaltbar; LEDs nacheinander einschalten, um dem Benutzer optisch die Drehrichtung anzuzeigen); hierzu ist hinterlegt, wie und wann jede LED für jede mögliche Bewegung geschaltet werden muss. 
* Ausgabe der SPI-Daten zum Schalten der LEDs 

Download der Sourcen [[Media: EZW-Sourcen_Rev111.zip|Sourcen Rev.111]] 

 

 

== PC-Software ==

Die PC-Software dient nur zur Kontrolle und Simulation des elektronischen Würfels. Es können Drehbewegungen an den realen Würfel gesendet werden, die dieser dann ausführt und seine aktualisierten Aufkleberfarben zurückschickt. Zudem zeigt die PC-Software die Lösungszeit an. 

[[Image:EZW Screenshot.png|thumb|left|200px|Screenshot PC-Software]] 

=== Autosolver ===

Als zusätzliches Feature war geplant eine Tutoriumsfunktion in die Hardware einzubauen. Nachdem ich mich etwas intensiver mit Konzept/Implementierung beschäftigt hatte, wurde mir schnell klar, dass das aus Ressourcengründen nicht autark in der Würfelelektronik abgehandelt werden kann (Laufzeit und/oder ROM/RAM-Bedarf). Darum beschäftige ich mich derzeit mit der Implementierung eines Autosolving-Algorithmus im PC, der aus jeder Situation heraus, den Zug vorschlägt, der einen Schritt in Richtung gelöster Würfel führt. 

Es gibt Lösungsalgorithmen, die versuchen mit möglichst wenig Zügen den Würfel zu lösen. Derzeit geht man davon aus, dass jede Würfelpermutation mit max. 20 Zügen gelöst werden kann (bewiesen ist das Maximum mit 23 Zügen). Das ist aber alles sehr theoretisch und die vorgeschlagenen Züge sind vom Menschen unmöglich nachzuvollziehen. (Zunächst kommen einem die ersten 12..15 Züge vollkommen willkürlich vor, danach "fallen" dann alle Steine innerhalb weniger Züge in ihre richtige Lage). 

Um auch einen praktischen Nutzen aus dem Autosolver zu ziehen, habe ich mich entschieden die "Spiegelmethode" (erstmalig im Spiegel 1981 veröffentlicht) als Tutorium zu implementieren. Beschreibung der Methoden auf [http://www.mathematische-basteleien.de/zauberwuerfel.htm '''Mathematische Basteleien'''] und [http://www.kantenkreuz.de/ '''Kantenkreuz''']. Oder für diejenigen, die sich das lieber als Youtube-Video reinziehen: [http://www.youtube.com/watch?v=mfvgeOarPBo '''Teil1'''], [http://www.youtube.com/watch?v=fVxn5geTOpM '''Teil2'''], [http://www.youtube.com/watch?v=bYsUfQ_KTxo '''Teil3''']. 

Der Vorteil dieser Methode ist, dass es viele Zwischenstationen gibt, die der Reihe nach zu erreichen sind, und die nur ein paar wenige Züge auseinander liegen. Dabei sind intuitive Züge (die jeder mehr oder weniger intuitiv durchführen kann, ohne genau zu wissen, was er tut) mit "vorgefertigten" Zugfolgen zu kombinieren. Die vorgefertigten Zugfolgen sollen ja hiermit eingeübt werden. Für einen Autosolver stellen die, für Menschen intuitiven Züge, natürlich ein Problem dar. Irgendwie müssen diese in einen Algorithmus gepackt werden. Der einfachste Algorithmus hierfür ist "[http://www.geocities.com/jaapsch/puzzles/theory.htm#godal '''God's algorithm''']", der stur alle Möglichkeiten durchprobiert. Bei 1019 verschiedenen Permutationen (beim 3x3x3 Würfel) ist dies natürlich in endlicher Rechenzeit nicht möglich (bei 1Mio. Zügen pro Sekunde wären das 1.3Mio. Jahre Rechenzeit). Aber wenn nur 4..6 Züge in die Zukunft gerechnet werden soll, so kann das in <1s errechnet werden (Werte meiner Implementierung). Und das reicht dann auch meist aus, um zur nächsten Zwischenstation zu kommen und hierfür Zugvorschläge zu machen. Um die Zugfolgen dann mechanisch/motorisch einzuüben, wird ein Wegpunkt gesetzt, von dem aus dann die Folge geübt werden kann. Auf Knopfdruck springt dann der Würfel wieder in die abgespeicherte Stellung zurück. Mit dem mechanischen Zauberwürfel ist das "geringfügig" aufwendiger. 

 

=== Ausblick/Verbesserungsideen ===

Zusätzlich zur "Spiegel-Methode" könnte man auch ein Blind-Folding-Tutorium einbauen. Blind-folding kann ich nämlich selbst (noch?) nicht. Beim Blind-Folding wird der Würfel verdreht, anschliessend darf der Würfel eine beliebig lange Zeit betrachtet werden und muss dann blind gelöst werden. Während des Lösungsvorganges darf der Würfel nicht mehr betrachtet werden (Augenbinde). Die Lösezeit ist die Summe aus Einprägephase und anschliessender Drehzeit. Beschreibung eines Blind-folding-Verfahrens auf [http://www.cubefreak.net/blindfoldcubing_guide.html '''CubeFreak''']. ([http://www.youtube.com/watch?v=IBIXzA3BvFs '''Beispiel-Video''']) 

 

 

== Probleme bei Planung und Durchführung ==

Folgende Probleme sind bei der Planung/Erstellung aufgetreten:

* '''mechanische Trägerkonstruktion''' für Würfel; wie halten die Platinen zusammen?; kann auf ein Gehäuse evtl. verzichtet werden? Wie wird vermieden, dass die überstehenden Taster beim Hinlegen des Würfels alle gedrückt werden? Wie kann der Würfel angefasst werden, ohne dass die Taster versehentlich betätigt werden?
* Liegen die Kanten- und Eck-'''LEDs nahe genug beisammen''', so dass man diese auch als solche erkennt? 
* '''Platzbedarf für Bauteile''' ist sehr hoch
** Bauteile dürfen nur auf der Unterseite platziert werden
** Platine muss umlaufenden Rand von 6mm zur Befestigung haben, in dem keine Bauteile (Unterseite) platziert werden dürfen
* Stromversorgungs- und Kommunikations'''kabel stören beim Lösen'''... muss in der nächsten Musterphase durch Akkus und Funk (Zigbee/XBee ersetzt werden)
* das räumliche Vorstellungsvermögen wird gut geschult... besonders bei der Umrechnung der PC-internen Datendarstellung (Würfel ist beschrieben durch Position und Orientierung der Steine) in die Aufkleberdarstellung (Farben der einzelnen LEDs).

 

=== '''Fazit''' ===

Der größte Nachteil an diesem Prototypen ist die schwierige Erkennung wo die Farben liegen, da diese zu weit im "Innern" entfernt von den Kanten liegen und somit nicht (ohne längere Übungszeit) auf einen Blick erkannt werden können. Beim mechanischen Zauberwürfel grenzen die farbigen Aufkleber direkt aneinander. Hier ist ein Abstand von 35mm bis zur Würfelkante. Beim "normalen" Speedcubing werden Zugfolgen trainiert, die dann nur noch mechanisch/motorisch abgerufen werden, ohne bewusst darüber nachzudenken. Gleiches konnte ich nach einiger Zeit auch in Bezug auf das Drücken der Tastenfolgen beobachten - das geschieht ebenso "natürlich" wie beim mechanischen Würfel - hätte ich so nicht unbedingt erwartet. Die Idee mit dem elektronischen Zauberwürfel habe ich zuvor im Internet noch nicht gesehen... naja, also wohl gute Idee gehabt, dachte ich mir. Bis ich zwei Monate nach Fertigstellung des Projekts, dieses Video fand ([http://www.youtube.com/watch?v=V4A_wfaScy4 '''Fentix''']) - aber das spielt auch in einer ganz anderen Liga. :-) 

 [[Image:EZW VideoScreenshot.jpg|200px]]

''Der elektronische Zauberwürfel in Aktion'' ([http://www.youtube.com/v/G6SVoK5OG90 '''Video''']) 

=== Interessante Details zum Zauberwürfel/Speedcubing/Links: ===

* Anzahl der verschiedenen Stellungen beim 3x3x3-Würfel: 4.3x1019; beim 4x4x4-Würfel: 1043; beim 5x5x5-Würfel: 1078.
* Der Weltrekord im Lösen des 3x3 Würfels liegt bei knapp unter 9s! ([http://www.youtube.com/watch?v=h6GnxKGicyg '''Video''']) 
* Optimal AutoSolver ([http://www.kociemba.org/cube.htm '''Webseite'''] von H.Kociemba)
* virtueller Würfel zum Selbstausprobieren ([http://gabbasoft.com/download.htm '''Win-Software'''])

 '''Kontakt''': André;  and_ref (at) canathome.de 

[[Category:Projekte]] [[Category:Wettbewerb]]

Datei:EZW-Sourcen Rev111.zip

2008-07-27T13:34:17Z

And ref:

Elektronischer Zauberwuerfel

2008-07-27T13:33:30Z

And ref: /* Mikrocontroller-Software/Firmware */

Der "Elektronische Zauberwürfel" ist die elektronische Variante des aus den 80er-Jahren bekannten Rubik's Magic Zauberwürfels. Es entsteht zunächst eine Studie/Prototyp, die zeigen soll,  ob die Spielidee des mechanischen Zauberwürfels auf eine elektronische Variante übertragbar ist und durch zusätzliche Features sinnvoll ergänzt werden kann. 

[[Image:EZW Rubiks3x3x3.jpg|thumb|80px|Rubiks Zauberwürfel]] 

 __TOC__

 

== Idee und Motivation ==

Die gängigen Rubiks Zauberwürfel haben 3x3x3 Steine. Neben dem Rubiks Revenge (4x4x4) und dem Rubiks Professor (5x5x5) gibt es keine käuflichen größeren Zauberwürfel - vermutlich aus mechanischen Gründen. Die virtuellen Würfel (PC-Software) lassen sich nicht in die Hand nehmen und auf natürliche Weise begreifen und lösen. Daher dachte ich zunächst einen 8x8x8 Würfel zu bauen, der ähnlich wie ein mechanischer Zauberwürfel lösbar sein sollte (In die Hand nehmen, drehen und die Farben suchen...). Nach kurzer Überlegung, wie viele Lampen und Taster ich dazu brauchen würde, habe ich die Idee gaaanz schnell aufgegeben und mich auf einen 3x3x3er konzentriert. (8x8x8: 512Felder zu je 6LEDs -> 3000LEDs)

Der Reiz den mechanischen Zauberwürfel überhaupt lösen zu können, verfliegt nach ein paar Tagen und es stellt sich die Frage: "Wie ''schnell'' kann ich den Zauberwürfel lösen?". Aus dem anfänglichen neugierigen Spiel wird eine technische Sportart, die auf folgende Punkte Wert legt:

* zeiteffizientes und/oder zugeffizientes Lösungsverfahren (Lösen mit möglichst wenigen Drehungen)
* definiertes Verdrehen vor dem eigentlichen Lösungsvorgang
* Zeitmessung des Lösungsvorgangs
* Protokollierung des Lernfortschritts (Lösungszeiten aufzeichnen und auswerten)

Der Elektronische Zauberwürfel soll diese Dinge vereinfachen.

 

== Features ==

Folgende Funktionen sollen umgesetzt werden:

* '''Auto-Scramble''' (Verdrehen des Zauberwürfels auf Knopfdruck)
* '''Automatische Zeitmessung''' (Competition Mode)
** Die LEDs des verdrehten Würfels werden erst nach Tastendruck freigegeben. Damit beginnt die Einprägungsphase.
** Nach Ablauf der Einprägungsphase (typisch 15s) beginnt die eigentliche Lösungszeit zu laufen. Dies kann vorgezogen werden, indem schon vor Ablauf der Einprägungsphase eine Taste gedrückt wird.
* Abspeichern der erzielten Zeiten zur '''Auswertung am PC'''
* mechanisches Drehen entfällt. Dadurch soll sich die Lösungszeit verringern lassen, da keine "Verklemmer" die Zeit beeinflussen. (Muss noch ausprobiert werden, ob nicht gerade das dann letztendlich den Reiz ausmacht)
* '''Tutorialfunktion''' zum Erlernen von Zugfolgen; schnelles Rücksetzen auf abgespeicherte Ausgangspositionen (Rückdrehen oder langwieriges Wiederherstellen der Position entfällt)
* '''Lösungsvorschläge'''; Würfel macht Vorschlag, wie er aus aktueller Situation gelöst werden kann (das dürfte die anspruchvollste Aufgabe sein)

 

== Mechanik ==

Beim elektronischen Zauberwürfel gibt es keine beweglichen Teile. Jede der sechs Seiten des Würfels besteht aus einem feststehenden 3x3-Feld aus LEDs. An allen Kanten sind Taster, die die ''gedachten'' beweglichen Teile in der gewünschten Drehrichtung weiterdrehen, d.h. die angezeigten Felder ändern ihre Farben. Übertragen auf einen mechanischen Würfel, würde sich diese Ebene bei einem Tastendruck dann um 90° in die gedrückte Richtung drehen.

 ''Die folgenden Bilder zeigen den bereits gefrästen, aber noch nicht verleimten Holzrahmen.''''' '''

In der Mitte jeder Seite ist das 3x3-LED-Feld. Jedes Feld besteht aus 6 farbigen EinzelLEDs, von denen immer nur eine leuchtet. Neben jeder Spalte und Zeile sitzen Taster. Pro Seite werden somit 12 Taster verbaut. 

{| width="100%" cellspacing="20" cellpadding="1" border="0"
|-
| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Holzrahmen4.jpg|thumb|150px|geplante Würfeloberseite]] Damit die Außenkante des Würfels höher ist als die verwendeten Taster (Schurter LSH SMD-Taster; Reichelt: TASTER 9315; Bauhöhe 5mm; Taster sollen nicht überstehen), müssen die Platinen 8mm tief liegen. -> Außenprofiltiefe der Kante: 8mm. Die Platinen sind mit einem umlaufenden Rand von 6mm entworfen. Damit ergibt sich die gewählte Profilform der Kantenteile.

 

 

| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Holzrahmen3.jpg|thumb|150px|Holzrahmen]] An einem Holzrahmen werden die Seitenplatinen befestigt. Kantenlänge des Holzwürfels: 10cm (möglicherweise etwas zu groß?!). Auf diesem Foto fehlen noch die Ausfräsungen der langen Kantenteile, damit die Platine (hier: links vorne) plan aufliegt und keine Aussparungen braucht)

|-
| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Holzrahmen1.jpg|thumb|150px|Einzelteile des Holzrahmens]] Der Holzrahmen besteht aus zwei verschiedenen Profilteilen:

* 4x Kantenteil -lang- (98mm)
* 8x Kantenteil -kurz- (70mm)

| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Holzrahmen2.jpg|thumb|150px|gefräste Kantenteile]] Die Profile haben die Kantenmaße: 20x20mm.

|-
| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Profilschnittbogen.png|thumb|150px|Profilschnittbogen]] Um mir die Sache vor dem Fräsen besser vorstellen zu können, habe ich mir die Kantenteile aus Papier gebastelt. :-)

| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Profilquerschnitt.png|thumb|150px|Profilquerschnitt]] Fräszeichnung

|}

 

== Elektronik ==

=== Konzept mit ''dimmbaren'' RGB-LEDs (verworfen) ===

Zunächst habe ich versucht die Anzahl der LEDs gering zu halten, und für jedes Feld eine RGB-TrueColor-LED vorgesehen. Der Vorteil dabei ist, es ist nur eine LED zu bestücken und es müssen nur 3 Ausgangskanäle (statt 6) verwendet werden - aber diese müssen dann auch dimmbar sein. Und da fing das Problem an...

Kurze Überschlagsrechnung für 162 dimmbare Kanäle (= 6 Seiten x 9 Felder x 3 LEDs) über 8Bit-SPI-Schieberegister (andere Ansteuermöglichkeit sehe ich nicht): [[Image:EZW PwmKonzept.png|thumb|300px|PWM-Konzept zur Ermittlung des zu versendenden Bytes aus der Tabelle der Helligkeitswerte]]

* '''162 Kanäle''' verteilt auf 6 Platinen (nur "ganze" Schieberegister pro Platine) -> 27Kanäle pro Würfelseite/Platine -> 4 Schieberegister pro Seite -> Summe: '''24 Schieberegister''' für den gesamten Würfel (wären theoretisch dann sogar 192 dimmbare Kanäle)
* damit die LEDs nicht flimmern sollten '''200Hz Wiederholrate''' gewählt werden (= 5ms Periodendauer).
* um vernünftige Farben mischen zu können, müssen diese mit '''10% Helligkeitsauflösung''' (lineare, zeitliche Auflösung der Periode; Wert 10% experimentell ermittelt) ansteuerbar sein.
* somit muss jede LED alle 500µs aktualisiert werden (5ms/10Steps=500µs). Bei 24 in Reihe geschalteten Schieberegistern, bleibt somit 20.8µs pro Schieberegister Zeit. (das entspricht also auch der Zeit pro rauszuschickendem Byte).
* -> SPI-Baudrate: 500µs/24Byte -> 2.6µs/Bit -> '''384kBit/s''' (das wäre noch problemlos machbar) 

'''Ergebnis''': D.h. es bleibt dem System genau 20µs, um zu berechnen, welches Byte als nächstes per SPI zu verschicken ist. In dieser Zeit müssen die Helligkeitswerte von 8LEDs in eine binäre Information umgesetzt werden (z.B. LED0: 80%; LED1: 100%...). Die hierfür entwickelte Testroutine (Lookuptable, zur Erhöhung der Ausgabegeschwindigkeit...) benögte dafür 45µs auf dem Zielsystem (HCS12C32@50MHz) und ist damit '''um den Faktor 2.5 zu langsam'''. Nebenbei sollte ja noch andere Dinge erledigt werden, wie z.B. Züge berechnen usw. '''''Damit ist das Konzept erst mal auf Eis gelegt.'''''

 

=== Konzept mit sechs Einzel-LEDs pro Feld ===

Nachdem das DimmKonzept aus Timinggründen nicht umsetzbar war, plante ich die Umsetzung von 6 Einzel-LEDs pro Feld. Jede Seite hat 9x6 EinzelLEDs -> pro Würfel sind das dann 324 zu verbauende LEDs, die über Schieberegister angesteuert werden und statisch leuchten sollen.

Elektrische Features:

* statische Ansteuerung der LEDs (kein Dimmen); LED Typ: Osram SmartLED 0603, da ausreichende Helligkeit bei kleinem Strom (1..5mA)
* Verwendung von 7 handelsüblichen 8Bit-Schieberegistern HC595 pro Seite (keine separate Treiberstufen oder spezielle LED-Treiberbausteine notwendig); der HC595 erlaubt an seinem EnableEingang durch eine PWM-Ansteuerung auch das Dimmen der angeschlossenen LEDs - allerdings alle auf einmal, so dass hiermit die Gesamthelligkeit des Würfels verringert werden kann.
* die 72 Taster werden ebenfalls über SPI-Schieberegister eingelesen (zeitgleich mit der Ausgabe der LED-Daten); HC165
* Piezopiepser zum Erzeugen von Hinweistönen
* es soll nur 1 Layout für alle 6 Seiten geben
* Kabelverbindung zwischen den 6 Seiten über Verbindung zur "Vorgängerseite" und "Nachfolgerseite". Damit ergibt sich eine Kette über die 6 Seiten.
* Stromversorgung über Kabel; Anbindung von Akkus (über Step-up/-down-Konverter) bereits über Lötpads vorgesehen.
* Datenanbindung an PC über RS232-Schnittstelle (Zeitmessung; Darstellung auf PC)
* Eeprom zum Abspeichern der erzielten Zeiten 
* ausgesuchter Prozessor: HCS12C32 @50MHz, da Gehäuse mit LQFP48 relativ klein ist (verglichen mit anderen HCS12-Derivaten) und hierfür bereits eine Entwicklungsumgebung und ein Referenzdesign vorlag; Die Realisierung ist natürlich ebenso mit anderen Controllern möglich. 

 

=== Schaltplan/Layout ===

{| width="600" cellspacing="1" cellpadding="1" border="0"
|-
| [[Image:EZW Schematic.PNG|thumb|left|150px|Schaltplan]]
| [[Image:EZW Layout top.PNG|thumb|left|150px|Layout (top)]]
| [[Image:EZW Layout bot.png|thumb|left|150px|Layout (bottom)]]
|}

 

{| width="80%" cellspacing="1" cellpadding="3" border="2"
|-
| bgcolor="#f7f7f7" |
== Technische Daten ==

'''Prozessor''': Freescale HCS12C32 (50MHz); 5V; 32k Flash (12k benutzt); 2k RAM (600Bytes benutzt) '''Schieberegister''': 42x 74HC595 zur LED-Ansteuerung; 12x 74HC165 zum Einlesen der Taster '''LEDs''': Gesamt: 324 Stück (54Stück von jeder Farbe: weiß, blau, rot, orange, grün, gelb); Gehäuse: 0603 '''Taster''': 72 Stück (12 auf jeder Seite) '''Gesamtstromaufnahme''': 50mA (LEDs auf 1% gedimmt)... 320mA (LEDs auf 100% gedimmt) bei 5V 

|}

 

 

 

== Fertige Hardware ==

Fotos der Elektronik

{| width="100%" cellspacing="20" cellpadding="1" border="0"
|-
| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Platine LED-Seite.jpg|thumb|150px|Platine: LED-Seite]] Jede Seite des Würfels besteht aus 6 dieser Platinen. Die Außenseite ist mit Tastern und LEDs bestückt...

| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Platine Prozessorseite.jpg|thumb|150px|Platine: Prozessor-Seite]] ... auf der Innenseite sitzt die Elektronik. Nur eine der sechs Platinen ist mit einem eigenen Prozessor ausgestattet - alle anderen tragen nur die Schieberegister.

|-
| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Gesamtansicht1.jpg|thumb|150px|Gesamtansicht]] So sieht der Würfel aus, wenn er zusammengebaut ist.

| width="50%" valign="top" bgcolor="#f7f7f7" |
[[Image:EZW Gesamtansicht2.jpg|thumb|150px|Gesamtansicht]]

 

|}

 

=== Ausblick/Verbesserungsideen ===

Statt der Verwendung von RGB-LEDs könnten auch 6 Einzel-LEDs verbaut werden, die allerdings nicht gedimmt werden, sondern mit verschiedenen zuschaltbaren Vorwiderständen angesteuert werden. Vorteil: LED in einem Gehäuse; kein "Versatz" bei unterschiedlichen Farben; zu prüfen, ob RGB-LED auch ohne Streuscheibe verwendet werden kann; sind Farben noch als solche erkennbar oder nur die 3 LED-Grundfarben? Als Tasteralternative könnten eventuell auch Sensortasten in Frage kommen?! QT1106 ([http://www.qprox.com/assets/Downloadablefile/QT1106_-8IR0.07-16262.pdf Datenblatt]) (3,55€ bei Farnell); evtl. zwischen den LEDs angeordnet... 

 

== Mikrocontroller-Software/Firmware ==

Die Software besteht aus den Modulen/Teilen für:

* RS232-Kommunikation (zum PC)
* SPI-Kommunikation (zu Tastern und LEDs) 
* Menü- und Ausgabefunktionen des Würfels (Set/Restore waypoint; History; Mischen; Prüfen ob Würfel gelöst ist; Animation beim Drehen; ShowCube)
* Funktionen zum Drehen des Würfels (L, R, U, D, F, B); "L" bedeutet z.B., dass die linke Seite des Würfels im Uhrzeigersinn gedreht werden soll; 
** Welche Steine werden durch die Drehbewegung an welche Position gebracht? Um den Überblick zu behalten, helfen die unten aufgeführten Einteilungen/Nummerierungen der Steine/Seiten/Stickers. 

{| width="600" cellspacing="1" cellpadding="1" border="0"
|-
| [[Image:EZW Cube AufteilungFelder 3d.png|thumb|left|400px|Anordnung der Felder (oben, vorne, rechts); (unten, hinten, links)]]
| [[Image:EZW Cube AufteilungFelder.png|thumb|left|200px]]
|}

 

Zusammengehalten wird die Software von einem Scheduler, der einen 10ms-Task und einen 100ms-Task zyklisch bedient. Der 100ms-Task wird als 500ms-Task benutzt (nur jeden 5.Durchgang ausführen), um folgende Aufgaben abwechselnd auszuführen: 

* aktuelle Konstellation (wie ist der Würfel aktuell angeordnet; alle Stickerfarben) zum PC senden 
* Zustand aller Taster zum PC senden 
* Im CompetitionMode die aktuell laufende Lösungszeit an PC senden (Zeitmessung findet ja im Würfel selbst statt). 

Der 10ms-Task erledigt folgende Aufgaben: 

* Einlesen und Entprellen der Taster 
* "Umordnen" des Würfels in Folge der erkannten Tastendrücke (das erfordert relativ viel Aufwand, um die ganzen Sticker auf die neue Position zu "kleben"; kann durch Verwendung von Const-Arrays und generischen Funktionen sicher noch deutlich optimiert werden) 
* Menübehandlung (Brightness +/-; StartCompetition; Scramble; AnimationMode on/off; Undo/Redo; Set/Restore Waypoint; ResetCube) 
* Auswerten der vom PC empfangenen Kommandos (Grundhelligkeit; vom PC ausgelöste Drehbewegung...) 
* Animation der Drehbewegung/Drehrichtungsanzeige (abschaltbar; LEDs nacheinander einschalten, um dem Benutzer optisch die Drehrichtung anzuzeigen); hierzu ist hinterlegt, wie und wann jede LED für jede mögliche Bewegung geschaltet werden muss. 
* Ausgabe der SPI-Daten zum Schalten der LEDs 

Download der Sourcen [[Media: EZW-Sourcen_Rev111.zip|Sourcen Rev.111]] 

 

 

== PC-Software ==

Die PC-Software dient nur zur Kontrolle und Simulation des elektronischen Würfels. Es können Drehbewegungen an den realen Würfel gesendet werden, die dieser dann ausführt und seine aktualisierten Aufkleberfarben zurückschickt. Zudem zeigt die PC-Software die Lösungszeit an. 

[[Image:EZW Screenshot.png|thumb|left|200px|Screenshot PC-Software]] 

=== Autosolver ===

Als zusätzliches Feature war geplant eine Tutoriumsfunktion in die Hardware einzubauen. Nachdem ich mich etwas intensiver mit Konzept/Implementierung beschäftigt hatte, wurde mir schnell klar, dass das aus Ressourcengründen nicht autark in der Würfelelektronik abgehandelt werden kann (Laufzeit und/oder ROM/RAM-Bedarf). Darum beschäftige ich mich derzeit mit der Implementierung eines Autosolving-Algorithmus im PC, der aus jeder Situation heraus, den Zug vorschlägt, der einen Schritt in Richtung gelöster Würfel führt. 

Es gibt Lösungsalgorithmen, die versuchen mit möglichst wenig Zügen den Würfel zu lösen. Derzeit geht man davon aus, dass jede Würfelpermutation mit max. 20 Zügen gelöst werden kann (bewiesen ist das Maximum mit 23 Zügen). Das ist aber alles sehr theoretisch und die vorgeschlagenen Züge sind vom Menschen unmöglich nachzuvollziehen. (Zunächst kommen einem die ersten 12..15 Züge vollkommen willkürlich vor, danach "fallen" dann alle Steine innerhalb weniger Züge in ihre richtige Lage). 

Um auch einen praktischen Nutzen aus dem Autosolver zu ziehen, habe ich mich entschieden die "Spiegelmethode" (erstmalig im Spiegel 1981 veröffentlicht) als Tutorium zu implementieren. Beschreibung der Methoden auf [http://www.mathematische-basteleien.de/zauberwuerfel.htm Mathematische Basteleien] und [http://www.kantenkreuz.de/ Kantenkreuz]. Oder für diejenigen, die sich das lieber als Youtube-Video reinziehen: [http://www.youtube.com/watch?v=mfvgeOarPBo Teil1], [http://www.youtube.com/watch?v=fVxn5geTOpM Teil2], [http://www.youtube.com/watch?v=bYsUfQ_KTxo Teil3]. 

Der Vorteil dieser Methode ist, dass es viele Zwischenstationen gibt, die der Reihe nach zu erreichen sind, und die nur ein paar wenige Züge auseinander liegen. Dabei sind intuitive Züge (die jeder mehr oder weniger intuitiv durchführen kann, ohne genau zu wissen, was er tut) mit "vorgefertigten" Zugfolgen zu kombinieren. Die vorgefertigten Zugfolgen sollen ja hiermit eingeübt werden. Für einen Autosolver stellen die, für Menschen intuitiven Züge, natürlich ein Problem dar. Irgendwie müssen diese in einen Algorithmus gepackt werden. Der einfachste Algorithmus hierfür ist "[http://www.geocities.com/jaapsch/puzzles/theory.htm#godal God's algorithm]", der stur alle Möglichkeiten durchprobiert. Bei 1019 verschiedenen Permutationen (beim 3x3x3 Würfel) ist dies natürlich in endlicher Rechenzeit nicht möglich (bei 1Mio. Zügen pro Sekunde wären das 1.3Mio. Jahre Rechenzeit). Aber wenn nur 4..6 Züge in die Zukunft gerechnet werden soll, so kann das in <1s errechnet werden (Werte meiner Implementierung). Und das reicht dann auch meist aus, um zur nächsten Zwischenstation zu kommen und hierfür Zugvorschläge zu machen. Um die Zugfolgen dann mechanisch/motorisch einzuüben, wird ein Wegpunkt gesetzt, von dem aus dann die Folge geübt werden kann. Auf Knopfdruck springt dann der Würfel wieder in die abgespeicherte Stellung zurück. Mit dem mechanischen Zauberwürfel ist das "geringfügig" aufwendiger. 

 

=== Ausblick/Verbesserungsideen ===

Zusätzlich zur "Spiegel-Methode" könnte man auch ein Blind-Folding-Tutorium einbauen. Blind-folding kann ich nämlich selbst (noch?) nicht. Beim Blind-Folding wird der Würfel verdreht, anschliessend darf der Würfel eine beliebig lange Zeit betrachtet werden und muss dann blind gelöst werden. Während des Lösungsvorganges darf der Würfel nicht mehr betrachtet werden (Augenbinde). Die Lösezeit ist die Summe aus Einprägephase und anschliessender Drehzeit. Beschreibung eines Blind-folding-Verfahrens auf [http://www.cubefreak.net/blindfoldcubing_guide.html CubeFreak]. ([http://www.youtube.com/watch?v=IBIXzA3BvFs Beispiel-Video]) 

 

 

== Probleme bei Planung und Durchführung ==

Folgende Probleme sind bei der Planung/Erstellung aufgetreten:

* '''mechanische Trägerkonstruktion''' für Würfel; wie halten die Platinen zusammen?; kann auf ein Gehäuse evtl. verzichtet werden? Wie wird vermieden, dass die überstehenden Taster beim Hinlegen des Würfels alle gedrückt werden? Wie kann der Würfel angefasst werden, ohne dass die Taster versehentlich betätigt werden?
* Liegen die Kanten- und Eck-'''LEDs nahe genug beisammen''', so dass man diese auch als solche erkennt? 
* '''Platzbedarf für Bauteile''' ist sehr hoch
** Bauteile dürfen nur auf der Unterseite platziert werden
** Platine muss umlaufenden Rand von 6mm zur Befestigung haben, in dem keine Bauteile (Unterseite) platziert werden dürfen
* Stromversorgungs- und Kommunikations'''kabel stören beim Lösen'''... muss in der nächsten Musterphase durch Akkus und Funk (Zigbee/XBee ersetzt werden)
* das räumliche Vorstellungsvermögen wird gut geschult... besonders bei der Umrechnung der PC-internen Datendarstellung (Würfel ist beschrieben durch Position und Orientierung der Steine) in die Aufkleberdarstellung (Farben der einzelnen LEDs).

 

=== '''Fazit''' ===

Der größte Nachteil an diesem Prototypen ist die schwierige Erkennung wo die Farben liegen, da diese zu weit im "Innern" entfernt von den Kanten liegen und somit nicht (ohne längere Übungszeit) auf einen Blick erkannt werden können. Beim mechanischen Zauberwürfel grenzen die farbigen Aufkleber direkt aneinander. Hier ist ein Abstand von 35mm bis zur Würfelkante. Beim "normalen" Speedcubing werden Zugfolgen trainiert, die dann nur noch mechanisch/motorisch abgerufen werden, ohne bewusst darüber nachzudenken. Gleiches konnte ich nach einiger Zeit auch in Bezug auf das Drücken der Tastenfolgen beobachten - das geschieht ebenso "natürlich" wie beim mechanischen Würfel - hätte ich so nicht unbedingt erwartet. Die Idee mit dem elektronischen Zauberwürfel habe ich zuvor im Internet noch nicht gesehen... naja, also wohl gute Idee gehabt, dachte ich mir. Bis ich zwei Monate nach Fertigstellung des Projekts, dieses Video fand ([http://www.youtube.com/watch?v=V4A_wfaScy4 Fentix]) - aber das spielt auch in einer ganz anderen Liga. :-) 

 [[Image:EZW VideoScreenshot.jpg|200px]]

''Der elektronische Zauberwürfel in Aktion'' ([http://www.youtube.com/v/G6SVoK5OG90 Video]) 

=== Interessante Details zum Zauberwürfel/Speedcubing/Links: ===

* Anzahl der verschiedenen Stellungen beim 3x3x3-Würfel: 4.3x1019; beim 4x4x4-Würfel: 1043; beim 5x5x5-Würfel: 1078.
* Der Weltrekord im Lösen des 3x3 Würfels liegt bei knapp unter 9s! ([http://www.youtube.com/watch?v=h6GnxKGicyg Video]) 
* Optimal AutoSolver ([http://www.kociemba.org/cube.htm Webseite] von H.Kociemba)
* virtueller Würfel zum Selbstausprobieren ([http://gabbasoft.com/download.htm Win-Software])

 '''Kontakt''': André;  and_ref (at) canathome.de 

[[Category:Projekte]] [[Category:Wettbewerb]]

Datei:EZW VideoScreenshot.jpg

2008-07-27T13:32:19Z

And ref:

Datei:EZW Screenshot.png

2008-07-27T13:32:02Z

And ref:

Datei:EZW Cube AufteilungFelder.png

2008-07-27T13:31:10Z

And ref:

Datei:EZW Cube AufteilungFelder 3d.png

2008-07-27T13:30:45Z

And ref:

Datei:EZW Gesamtansicht2.jpg

2008-07-27T13:30:01Z

And ref:

Datei:EZW Gesamtansicht1.jpg

2008-07-27T13:28:52Z

And ref:

Datei:EZW Platine Prozessorseite.jpg

2008-07-27T13:28:08Z

And ref:

Datei:EZW Platine LED-Seite.jpg

2008-07-27T13:27:27Z

And ref:

Datei:EZW Layout bot.png

2008-07-27T13:26:40Z

And ref:

Datei:EZW Layout top.PNG

2008-07-27T13:26:18Z

And ref:

Datei:EZW Schematic.PNG

2008-07-27T13:25:50Z

And ref:

Datei:EZW PwmKonzept.png

2008-07-27T13:25:10Z

And ref:

Datei:EZW Profilquerschnitt.png

2008-07-27T13:24:57Z

And ref:

Datei:EZW Profilschnittbogen.png

2008-07-27T13:24:43Z

And ref:

Datei:EZW Holzrahmen2.jpg

2008-07-27T13:24:29Z

And ref:

Datei:EZW Holzrahmen1.jpg

2008-07-27T13:24:14Z

And ref: