GPS-Racing LUA-Script

David Beach hat sein LUA-Script GPS-Racing für OpenTX 2.1 veröffentlicht.





Außerdem gibt es von ihm eine neue Firmware für das FrSky GPS mit 10Hz Datenrate.

Das Script funktioniert natürlich auch mit dem openXsensor. Auf den ersten Blick kann man das Script sogar vereinfachen, da der openXsensor Heading direkt liefert. Das FrSky GPS übermittelt heading nicht, deswegen muss heading für dieses im LUA-Script errechnet werden.

Gruß Bernd

Hy,
ich frage mich immer wie die ominösen 10Hz neue Pos-Daten gehen soll ???

Ein GPS-Satellit sendet mit popeligen 50bit/s

Ein kompletter Datensatz hat 25 Rahmen a 1500 bit, dauert 12,5 min

Ein Rahmen hat 1500bit,
Ein Subrahmen hat 300 bit (=5 Subrahmen pro Rahmen)
Ein Word im Subrahmen 30 bit =0,6s (= 10 Worte im Subrahmen)

Mehr als 0,6s = 1,66 Hz ist einfach technisch nicht drinn um echte neue Pos-Daten zu bekommen.

................
nicht verwechseln mit NMEA 0183
NMEA 0183 ist nur das Protokoll vom GPS-Empänger zur Weiterverarbeitung PC, Handy usw
mit 4800 bit/s oder 9600...

Also ist die u-blox Angabe hier
wenig sinnvoll?

Quelle: https://www.u-blox.com/sites/defaul...ments/NEO-7_ProductSummary_(UBX-13003342).pdf

Wir sprechen ja nicht von einem ortsfesten GPS, sondern von einem bewegten. Ich kann mir nicht vorstellen, dass ein Verkehrsflugzeug, das sich mit 250 m/s bewegt, nur alle paar Hundert Meter eine neue Position bekommt. Die GPS sollten ja auch in der Lage sein, zu interpolieren.

Die Praxis mit meinem 5Hz openXsensor GPS zeigt auch, dass sich die Positions- und Geschwindigkeitsdaten in dieser Frequenz ändern. Bei 10 Hz habe ich allerdings bei den von mir geflogenen Geschwindigkeiten keinen weiteren Vorteil gesehen

Gruß Bernd

"For objects moving with speed of 1,000km/h,
GPS receiver with update rate more than 200Hz must be used."

Da ist also noch ein bisschen Luft nach oben.

Gruß Bernd

the-suitability-of-gps-receivers-update-rates-for-navigation-applications

Hy,

klar gibt es Differenzial-GPS und A-GPS und hochwertige Industrie-GPS, Militär-GPS und Luftfahrt-GPS.
für Hochgeschwindigkeit die dann schnell 10000-100000€ kosten.

Mir geht es ja nur um diese einfachen 0815-GPS-Empfänger im RC-Bereich.

Wenn man ein Multikanal-GPS verwendet, der auch tatsächlich 12-14 Satelliten empfängt und auch verarbeitet,
sieht das ganze schon anders aus.


4 Sats braucht man mind für eine 3D -Position und das geht nicht schneller als 1.6Hz

Je mehr Sats empfangen und auch tatsächlich gleichzeitig verarbeitet werden
desto schneller kann eine neue Pos errechnet werden.

Bei tatsächlichen empfangen 7 Sats kommt man dann auf max ca 5Hz


Klar gibt es 14 Kanal oder auch 66 Kanal Sat-Empfänger für theoretische 100Hz
Blos man muss auch möglichst viele Sats empfangen können und die dürfen nicht nur knapp über dem Horizont stehen.
Dazu sind aber min 4 Antennen mit Multikanal nötig.


Trotzdem wird die Position selbst nicht genauer da diese künstlich (wg Militär) verfälscht sind.
Das kann man mit einem Differenzial-GPS ausgleichen.
Dann muss aber ein Langwellenempfänger mit dabei sein, um die Korrekturwerte zu empfangen
wie meist im Autoradio und GPS verbaut

-----------------------------------------
Nochmal:
Es geht nicht um das Pos-update vom GPS-Empfänger zum PC
nach NMEA0183 Protokoll das mit 4800, 9600 .... 118000 bit/s laufen kann
und mit 1Hz, 5Hz, 10Hz vom GPS-Empfänger zum PC/Handy/RC-Sender updatet.
Das ist witzlos wenn zu wenige Sats empfangen werden nutzt das alles nichts.

Ich hoffe David veröffentlich auch noch den Sourcecode von diesem Script.
Mich interessiert nämlich die Heading Berechnung, die das original FrSky GPS nicht liefert.

Auch hat das Kurs-Dreieck bei ihm eine Mindest Seitenlänge von 100m , bei uns Schiffchenfahrern ist die Seitenlänge des Bojendreiecks nur 30m.

Solange man nicht wieder auf die originale FW des GPS zurückflashen kann werde ich auch an dieser Stelle keine Experimente wagen.

Mal sehen wann ich dazu komme das Script auch Real zu testen....

Ralf

Für Absatz 3 gibt es die perfekte Lösung für 15.--: o...X......
Udo hatte hier aber auch ein Script bearbeitet, das Heading berechnet: LUA für Anfänger.

Gruß Bernd

@ Bernd
Das mit OpenX Sensor werde ich mir irgendwann mal zu Gemüte führen wenn das nächste Projekt ansteht.
Aktuell ist halt das FrSky GPS schon vorhanden.
( für meine Zwecke nämlich die Geschwindigkeitsabschätzung zur Propellerabstimmung auch völlig ausreichend...)

Zu dem Skript welches Udo überarbeitet hatte, da wird die Richtung auch relativ zum Startpunkt berechnet, ich such aber etwas das mir die tatsächliche Himmelsrichtung ausgibt....

Am Ende wirds wohl das einfachste sein auf das alternative GPS umzusteigen.
Ralf

Gibt es eigentlich auch den Punkt Start/Ziellinie, ohne Streckenverlauf, wo man relativen Linienlänge angeben kann, das wäre ja recht Praktisch für Individuelle Streckenmessung.
In der Anleitung hatte ich nur mehrere Streckenarten gefunden, ist ja alles schlecht auf eine vor Ort aufgebaute Strecke anwendbar

Hab ich bisher noch nicht gefunden, mach ich immer hinterher bei der Auswertung der Logs mit Google Earth...
Ralf

In der zweiten LUA-Datei kannst du feste Werte eingeben. Da sollte eine Anpassung an deinen Kurs möglich sein. @Ralf: Dort kann man auch die Streckenlänge eingeben, für ein 1km Dreieck sind das ~ 207 m, siehe hier: rc-groups.

Es hat gestern abend nur noch für den ersten GPS-Racing-Flug gereicht, man muss sich aber erst mal an die akustische Führung gewöhnen. Hier das sensationelle Ergebnis aus 100m Höhe: Zwei 1km Dreiecke geschafft, mit einer Durchschnittgeschwindigkeit von 12,5 km/h. Das würde ich fast laufen Aber es ist eine ganz neue Herausforderung und macht Spaß, vor Allem, wenn man sich erstmal anstellt wie der letzte Depp (und über sich selbst lachen kann). Die Fortschritte sind am Anfang dramatisch groß, wie immer.

Gruß Bernd

@ Bernd:
Die Eingabemöglichkeit hatte ich schon gefunden.
Es lassen sich nur Seitenlängen über 100m eingeben, das Bojendreieck für den ECO-Kurs bei uns hat aber nur 30m Kantenlänge...

Ralf

ps OpenXsensor GPS mit Heading Anzeige läuft....

Mit den kurspunkten hatte ich auch schon gesehen, müsstest dann aber immer den Kurs ausmessen und eingeben. Ich meinte wirklich nur Variablen Punkt über GPS Koordinaten, den man dann bestätigt, also Kopter in die mitte der Start/Ziellinie stellen, und mit Taste oder ähnlichen als Koordinaten einlesen

Den Startpunkt kannst Du ja genau so festlegen, wobei es mich erstmal irritiert hat, dass beim Setup immer die Koordinaten (0,0) stehen bleiben. Ich habe eine Zeitlang auf den GPS-Fix gewartet und dass dort meine Koordinaten erscheinen und ich dann "Set" drücken kann. Aber der Fix wird auf dem Setup-Screen nicht angezeigt. Deswegen habe ich dann im Telemetriescreen nachgesehen, ob ich einen stabilen Fix habe und habe dann erst "Set" auf der Seite gedrückt. Dann erscheinen die Koordinaten auch. Besser wäre es, wenn auf diesem Setupscreen auch die aktuellen Koordinaten und damit der Fix zu sehen sind.

Die anderen Punkte eines Parcours müsste man dann mit dem Schmartfon ermitteln, oder zu Hause mit Google Earth. Deine Idee wäre, den Kurs abzugehen und bei den Wendepunkten dann die Koordinaten zu speichern. Mal sehen, ob da noch was kommt. Mit den festen Kursen funktioniert es jedenfalls jetzt schon einwandfrei.

Dazu legt man mit "Direction" übrigens die Richtung vom Startpunkt (= da, wo man "Set" gedrückt hat) bis zum ersten Wendepunkt fest. Damit sind auch die anderen Wendepunkte, beim Dreieck z.B., definiert. Mit 0 fliegt man also erst mal nach Norden, mit 90 nach Osten u.s.w..

Das Ganze ist um Einiges anspruchsvoller als reines Thermikfliegen, weil man nicht nur Höhe macht und abturnt, sondern versuchen muss, die beiden Aufgaben, Höhe machen und Dreieck fliegen, bestmöglich zu kombinieren. Das GPS-Race-Establishment fliegt ja irgendwelche teuren Apparate mit teuren 1:3 Scaleseglern durch die Gegend, mal sehen, ob sich eine alternative lowcost-hightech-Szene um diesen Ansatz etablieren kann.

Gruß Bernd

Ich meinte wirklich nur den Startpunkt, alles andere hat für die Taranis in meinen Augen keine Bewandtnis, ich meine rein Strecke und Wichtiger Rundenzeit zu messen, Strecke wird dann nicht per Software sondern mit Tor/Fahnen fest gelegt

OK, das wird aber eher schwierig mit dem Script, es ist halt auf Flächenflieger gestrickt. Wenn es nur zum Training benutzt wird, könnte das hier funktionieren:

Aber du müsstest die "Distanz" von Start/Ziel (=WP1) weggehen, z.B. 100 m und dann dort den Startpunkt setzen. Wo dann dein eigenlicher Kurs ist, ist egal, du musst nur mindestens von WP1 nach WP2 fliegen, dann zählt die Runde, wenn du WP1 wieder erreicht hast.

Da zählen ja die 2 Linien
Wir haben doch einige die auch im lua fit sind, müsste es nicht möglich sein, aus dem vorhandenen Programm ne einfache Version zu stricken, die eben nur das macht.
Aufwendiger aber am sichersten wäre da eine 3 punkt Gps messung.
1. Linkes Ende der Start/Stop Linie
2. Rechtes Ende der Start/Stop Linie
3. Punkt 1-2m vor der Linie zur Überflugrichtungsbestimmung

Kann mir aber nicht vorstellen wie Aufwendig sowas für die Funke zu berechnen ist, wenn die Linie schräg zum Koordinatennetz liegt

I shems hat das jetzt quelloffene Script von David Beach auf die aktuelle OpenTX Version portiert. Mit I shems' Loader läuft es auch auf den Hori.

GPS Racing Discussion - Page 22 - RC Groups