Leistungsermittlung von Modellseglern mit openXsensor OpenTX und Taranis

Norbert · Feb 7, 2016

Hallo Bernd,

nachmals eine Nachfrage zum GPS:

Wenn das GPS keine gültigen Daten liefert, erscheinen die Werte für Längen und Breitengrad und Speed gar nicht?

Von den anderen kenne ich halt, dass dann 00.00000 00.0000 usw in den Datenfeldern kommt.

Das OXS bringt dann gar keine Datenfelder in der Telemetrie??

Oder anders herum gefragt - ohne angeschlossenes GPS erscheinen keine Datenfelder?

Nochmals die Bitte: Könnte ich von dir dein funktionierendes config file haben, um eine Fehlerquelle auszuschließen?

Ich habe das UBLOX Neo8 GPS.

Schönen Sonntag trotz meiner Nerverei. Es mach mich wahnsinnig, wenn etwas nicht geht und ich weiss nicht warum, weil ich im Dunklen tappe.

Norbert

Norbert · Feb 7, 2016

Sorry, hat sich eben alles erlegigt.

Habe jetzt das GPS für 15min im Freien liegen lassen. Hat sich eben gemeldet und GPS Daten sind da.

Dh ohne gültigen GPS Empfang und Daten meldet der OXS keine Datenfelder. Nicht wie die anderen, die die leeren Datenfelder ( 000000) melden. Ich war einfach zu ungeduldig, der erste Fix des GPS dauert nicht wie im Datenblatt angegeben irgendwelche 53sec oder so ähnlich sondern ungleich länger.

Dann kann ich ja jetzt den Vergleich zwischen den verschiedenen GPS machen und werde mal das ganze filmen, weil immer angezweifelt wird, dass da so ein starkes delay drin ist. Vielleicht hat sich bei der aktuelle Version 2.1.7 was getan.

Norbert

Carbonator · Feb 7, 2016

Schön dass es funktioniert. Ich wollte gerade einen Probeaufbau machen. Ich schicke nämlich ungern config-files, die nicht getestet sind, das kann mehr verwirren, als es bringt. Ab und zu ist doch ein Leichtsinnsfehler drin.

Mit dem oXs GPS hatte ich nie den Eindruck, dass es ein großes delay gibt. Ich bin mal gespannt was bei Dir rauskommt. Bei diesem Log sieht es sogar so aus, dass der GPS-Speed schneller kommt, als der gefilterte airspeed:

Gruß Bernd

Norbert · Feb 9, 2016

Hallo Bernd,

WOW - das OXS GPS ist deutlich schneller als FrSky und SM-GPS-Logger2 - ich bin begeistert.

Kein Überschießen der Entfernung um 70 - 100 mtr ( je nach Speed ) und sekundenlanges Nachzählen der Geschwindigkeit und Entfernung. Innerhalb von 2 sec stehen alle Werte.

Habe eben im direkten Vergleich die 3 GPS im Auto getestet.

So - jetzt zur Kehrseite meines OXS GPS.

Der Fix dauert gefühlt ewig und er ist Empfangsseitig unempfindlich. Ich habe über der Terasse ein Glasdach mit Aluträgern im 80 cm Abstand. Dort fixt er in 2mtr Abstand zur Hauswand nicht. Die anderen beiden sind in 2 oder 3 min fertig. Erst wenn ich ihn ausserhalb des Daches hinlege loggt er. Lege ich ihn zurück unter das Vordach verliert er zeitweise den fix. Das ist aber Problem des GPS Moduls - nicht OXS.

zu OXS:

Wenn man das GPS versucht neu in Telemetrie einzubinden und im TelemMenue suchen lässt findet er ---- nichts.
Das war anfangs zusätzlich mein Problem, neben dem dass mein GPS Modul nicht unterm Glasdach loggt.
Erst wenn er den fix hat, erscheinen auch die Datenfelder.
Ausserdem ist meine Geschwindigkeitsausgabe in km/h um den Faktor 1,8 zu hoch, Ich werde jetzt mal in der Config diesen Punkt ändern, ob sich der Rechenfaktor ändert. Vielleicht habe ich da was falsch verstanden.

Was ich mir wünsche:

- Die Datenfelder sofort auszugeben - entweder mit 0 oder was offenbar auch geht leer.
- Anzahl Satelliten als Datenfeld, dass man ein "Warnung" drauf machen kann, wenn er mehr als 3 Satelliten gefunden hat
- Berechnung der Distanz und Richtung intern, ab dem Nullpunkt, den man per Fernsteuersignal setzen kann.

So, jetzt muss ich wieder etwas sinnvolles tun, nicht nur spielen.

Norbert

strgaltdel · Feb 9, 2016

Hallo,

wo wir schon bei der "Wunschliste" sind:
ich glaube die Koordinaten des Homepoints werden auch nicht übergeben (ist das überhaupt üblich ?)
Waere zumindestens schön, wenn der Arduino einen Status ausgeben könnte, ob ein Homepoint zugewiesen/gefunden wurde.

@ Norbert:
meinst Du wirklich "Warnung, wenn mehr als 3 Sats gefunden" ?
ich würde die Warnung eher bei weniger als 3 Sats ausgeben.

Gruß
udo

Norbert · Feb 9, 2016

Hallo, Bernd,

Das mit der Wunschliste war natürlich Spaß - oder als Denkanstoß für den Entwickler.

Grundsätzlich kann man den Nullpunkt im Sender setzen, wenn man auf Reset Telemetriewerte geht. Dann wird der momentane Punkt zu "0" gesetzt und von hier aus gemessen. Ist eine Funktion von OpenTx. Interessant ist das Ganze, um zB beim GPS Dreiecksfliegen seine Umkehrpunkte zu treffen.

Wir "Warnung" war bewusst in Hochkomma gesetzt. Wenn man es anders herum macht, labert der Sender dauernd, solange er sucht. Er soll sich melden, wenn er die 3 o der 4 oder--- gefunden hat, dass man weiss, jetzt kann es los gehen und die Meldung aus schalten.

Klar kann ich zB auch die Uhrzeit nehmen als Signal, jetzt hat er einen Fix.

Norbert

Carbonator · Feb 9, 2016

Norbert hat gesagt.:

Hallo Norbert,

ich habe nur zwei Neo7 im Einsatz, die aber beide schneller fixen, als das FrSky GPS. Dein Neo8 sollte eher noch besser sein. Vielleicht hast du eine Niete gezogen. Über der Antenne ist nichts Leitendes? Wenn der Fix entsprechend schnell kommt, ist auch das Einlesen der Sensoren schnell erledigt. Man muss es ja nur einmal machen und nicht bei jedem Flug.

Edit: ich hab mal schnell mein Popel N32 GPS angeschlossen, unter dem Dachfenster hatte ich nach 25s den ersten Fix. Da stimmt was nicht mit deinem Neo8

Ich habe etliche GPS-Flüge gemacht und nach meiner Erfahrung ist der Empfang im Modell absolut unkritisch, außer bei negativen Figuren natürlich. Keine Bäume, keine Häuser, d.h. immer optimaler Empfang. Auf die Anzeige der Sat´s kann man dadurch echt verzichten und belastet den Telemetriekanal dadurch weniger. Aus demselben Grund werden auch nur GPS-Daten übertragen, wenn ein Fix da ist. So kann man mit oder ohne GPS fliegen, ohne den Sketch ändern zu müssen.

Mstrens macht nur alle zeitkritischen Berechnungen im Sensor, Berechnungen wie GPS-Distanz und -Richtung können problemlos im Sender gemacht werden. Dazu gibt es bereits einige schöne LUA-Scripte.

Gruß Bernd

Norbert · Feb 9, 2016

Danke Bernd für deine ausführliche Antwort,

ja eigentlich sollte lt Datenblatt der Neo8 besser sein. Ausser Schrumpfschlauch ist da nichts dazwischen oder drauf.

Dann werde ich mir noch so einen Popel GPS besorgen, der gefällt mir eh gut, da er noch in das Flugdaten Paket reinpasst.

Norbert

Carbonator · Feb 11, 2016

Norbert hat gesagt.:

https://github.com/opentx/opentx/issues/3043

Norbert · Feb 11, 2016

Hallo Bernd,

Der github link bezieht sich auf ASpeed - ich sprach vom GFPS -Speed.

Bin gerade wieder mit OXS beschäftigt und habe eine Minimal Vario Config zusammengebastelt.

Als nächstes ist das GPS dran, da werde ich das mit dem Umrechenfaktor nochmals genauer untersuchen.

Übrigens - kennst du diese Passage in der Config_discription:

**** xx - Reserved for developer. **************************************************************************************
* DEBUG must be activated here when you want to debug one or several functions in some other files.
* You can then select the parts that you want to debug by uncommenting the specifics DEBUG parameters you want in each file
* Note: OXS allows to transmit 3 fields named TEST1, TEST2, TEST3. You can fill those fields with whatever you want where you want if you want to transmit additional data to the Tx.
* Just fill in test1Value (or 2, 3) with an int32_t and test1ValueAvailable (or 2, 3) with true and add those OXS measurements in the data to be sent section.
************************************************************************************************************************

Ich habe mal die GPS.h und GSP.CPP durchgesehen.

Da fand ich:

// *********** GPS calculated data
int16_t GPS_distance ; // distance from home (first location) in m
int16_t GPS_bearing ; // bearing from home in degrees
bool GPS_fix ; // true if gps data are available.
uint8_t GPS_numSat;

Also alle meine "Wünsche" sind im vorauseilender Weitsicht bereits erfüllt.

Muss nur noch verstehen, wie ich die Daten in die Test1 - 3 schaufeln muss

Norbert

Carbonator · Feb 11, 2016

Norbert hat gesagt.:

Schaun mer mal

Gruß Bernd

Bussard · Feb 13, 2016

Habe noch auf den Sensor mit Beschleunigungsmessung gewartet, am Freitag kam das Brieflein an.
Diese "kleinen" Vorbereitungen können schön in die Abend-Freizeit gehen.

Der GY-86 Beschleunigungssensor hat ja nun vordefinierte Achsen X und Y. Müßte dann nicht für eine korrekte Verarbeitung der Meßwerte die Einbaurichtung relativ genau eingehalten werden (ich denke X in Flugrichtung und Y nach oben (Z nach rechts) wie im üblichen Koordinatensystem)?
Oder wird nur der Betrag der Beschleunigung, egal auf welcher Ache, verrechnet? Bin leider nicht in der Lage, das Programm ausreichend zu verstehen, um diese Frage selbst zu beantworten.

Übrigens war hier gestern und heute überwiegend sehr schönes Wetter -> warum ich dann wieder einmal in einem der seltenen Maulwurfshügel gelandet bin, weiß ich nicht - vielleicht ist ja jetzt schon ein Erdhügeldetektor eingebaut?

Gruß Bussard

Carbonator · Feb 13, 2016

Bussard hat gesagt.:

Ohne groß nachzudenken, habe ich X in Flugrichtung und Y nach links deuten lassen. Z also vertikal und es hat funktioniert. Mstrens hat eine Konfigurationsroutine für den Acc Offset integriert und in der oXs.config.description.h beschrieben. Es soll aber auch User geben, die einfach die Standardwerte nehmen??? Wichtig ist, dass der GY86 parallel zur Flugebene montiert ist.

Bussard hat gesagt.:

Ornungsgemäß eingemessen und leistungsoptimiert hättest Du es locker drübergeschafft

Übrigens hatte ich heute einen Dialog mit mstrens, wegen der Ausregelung der Phygoide. Ich habe vorgeschlagen, dass er einen PID-Controller integriert. Er hat erst eine LUA-Lösung vorgeschlagen, dann einen PID-Controller mit I und D = 0, was aber letztlich nur ein Proportional-Mischer + Offset ist. Seine Idee war, den Offset mit einem Poti oder einer GVar vorzugeben. Danach ist mir erst klargeworden, wie genial und genial einfach das ist:

Das heißt, wir mischen den VSpeed auf das Höhenruder mit einem Offset, das von einem Poti eingestellt wird. Angenommen VSpeed schwankt zwischen -0,45 und -0,48 m/s ungetrimmt, dann sollten wir idealerweise 0,465 Offset einstellen. Das treffen wir natürlich nicht genau, das bedeutet, wir trimmen durch das Poti letztendlich Höhe in irgendeine Richtung, unser Flieger wird schneller oder langsamer, bis er die Trimmgeschwindigkeit ereicht hat. So können wir mit dem Poti den ganzen EWD-Bereich durchgehen und haben gleichzeitig die Regelfunktion vom VSpeed-Mischer.

Muss jetzt nur noch funktionieren. Bin mal gespannt.

Gruß Bernd

Tempo · Feb 13, 2016

Anti-Phygoide-Automatik

Carbonator hat gesagt.:

Das Rad "Ausregeln der Phygoide" ist schon erfunden, siehe da:
http://www.rc-network.de/magazin/artikel_10/art_10-049/art_049-01.html

Hier das PDF:
Anhang anzeigen Phygoidenregler.pdf

Viel Erfolg beim digitalen Regelkreis mit dem openXsensor !

Carbonator · Feb 14, 2016

Hallo Tempo,

danke für die guten Wünsche und den Artikel, den ich allerdings schon kannte. Wie ist Deine persönliche Meinung zu dem Ansatz, die Phygoide mit einem VSpeed-Mischer mit einem wählbaren Offset auszuregeln? Diesen Offset könnte man übrigens auch als Vsoll bezeichnen, weil er letzten Endes die Fluggeschwindigkeit über den Anstellwinkel einstellt.

Noch ein Hinweis: Die Messung funktioniert auch ohne das automatische Ausregeln, wenn der Pilot mit empfindlichem Vario gegensteuert, aber das erfordert etwas Training und Antizipation.

Grün: VSpeed
Blau: Höhenruder
Rot: Dauer der gültigen Messperiode (beginnt bei 0, wenn Airspeed außerhalb der Toleranz ist)

Carbonator · Feb 16, 2016

Gerade bekam ich einen Hinweis auf einen 3D gedruckten Halter für das eagletree Pitot-Rohr. Sieht richtig chic aus, eventuell kann man auch die Drucksensoren im Fuß unterbringen und nur mit 4 dünnen Drähtchen für i2c und Stromversorgung zum Arduino fahren.

3d-printed-pitot-tube-mount

strgaltdel · Feb 29, 2016

Hallo Bernd,

ich habe ja von Dir mal eine Bsp-config erhalten.
Bei der Durchschau ist mir aufgefallen, dass sie Parameter enthält, die nicht "im Standard" beschrieben sind.

Es handelt sich da um den letzten Block (.. unterhalb des debug Bereichs..)

#define BASED_ON_AIRSPEED 0
#define BASED_ON_GPS_SPEED 1
#define AVERAGING_DELAY_MILLISEC AVERAGING_TOLERANCE * 100
#if defined( DISPLAY_ACC_OFFSET ) && defined( USE_6050 )
#define DEBUG
#endif

#define FIRST_BARO 1
#define SECOND_BARO 2
#define AVERAGE_FIRST_SECOND 4
#define AIRSPEED_COMPENSATED 3
#define BARO_AND_IMU 5
#define PPM_SELECTION 6

#include <Arduino.h>
struct ONE_MEASUREMENT {
uint8_t available ;
int32_t value ;
} ;

#define FRSKY_SPORT 1
#define FRSKY_HUB 2
#define FRSKY_SPORT_HUB 3
#define MULTIPLEX 4
#define HOTT 5

#define SECONDS_SINCE_T0 32
#define AVERAGE_VSPEED_SINCE_TO 33

#ifdef DEBUG
//#include "HardwareSerial.h"
#endif

#ifdef GPS_INSTALLED
//#include "HardwareSerial.h"
#endif

Gibt es dazu weitere Infos, wenn ja wo,
oder kannst du ggf etwas dazu erläutern?

Manches sieht nach erweitertem, nicht dokumentiertem Feintuning aus,
manches nach debug Optionen,
manches erschliesst sich mir überhaupt nicht...

Oder alles nur debug Optionen, die nicht wirklich notwendig sind ?

Danke & Gruß
Udo

Carbonator · Feb 29, 2016

strgaltdel hat gesagt.:

Hallo Udo,

diesen Bereich habe ich noch nie angeschaut. Mstrens baut sich ziemlich ausgefeilte debug-Routinen ein und wenn es irgendwo klemmt, findet er so ziemlich schnell die Ursache. Also halte ich mich da raus und schließe ihn nur in mein Abendgebet ein und wünsche ihm ein langes Leben

Gruß Bernd

Carbonator · Mrz 26, 2016

Im aktuellen oXs Master wurde zusätzlich die Option "indicated airspeed", mstrens nennt sie "normalised airspeed" eingeführt. Damit werden die Leistungsparameter vergleichbar, weil sie unabhängig von der momentanen Luftdichte ermittelt werden.

Code:

// --------- 5 - Airspeed settings ---------
#define AIRSPEED    MS4525
//#define AIRSPEED_AT_SEA_LEVEL_AND_15C // if this line is commented, airspeed is calculated using
baro pressure and temperature (so being "true" airspeed instead of normalised airspeed)

Im Wikipedia Fluggeschwindigkeit sind die Unterschiede gut erklärt.

Das heißt: Leistungsermittlung mit indicated/normalised airspeed durchführen, die wahre Fluggeschwindigkeit gegenüber der Luft wie bisher ermitteln - die Zeile bleibt dazu kommentiert, wie oben. Die Unterschiede bewegen sich für uns Modellflieger im niedrigen, einstelligen Prozentbereich.

Gruß Bernd

Carbonator · Mai 1, 2016

Norbert hat gesagt.:

Ich habe bei mir alles runderneuert, OpenTX 2.1.8 und der aktuelle oXs Master und habe gestern Messflüge gemacht: Wenn Airspeed und GPS Speed von oXs in knots gesendet werden und in der Telemetrie km/h als Einheit für die beiden Felder gewählt wird, dann stimmen die Werte im Sender/Log.

OpenTX rechnet also selbst um, was früher, glaube ich, nicht der Fall war.

Gruß Bernd

Leistungsermittlung von Modellseglern mit openXsensor OpenTX und Taranis

Erfahrener Benutzer

Erfahrener Benutzer

Allerhopp ;)

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Allerhopp ;)

Erfahrener Benutzer

Allerhopp ;)

Erfahrener Benutzer

Allerhopp ;)

Erfahrener Benutzer

Anhänge

Allerhopp ;)

Erfahrener Benutzer

Allerhopp ;)

Allerhopp ;)

Erfahrener Benutzer

Allerhopp ;)

Allerhopp ;)

Allerhopp ;)