Smartport Sensoren im Sender

In der Horus hat FrSky ein GPS und einen Lagesensor integriert. Für ein anderes Projekt hatte ich schonmal einen GY-521 ACC/Gyro Sensor über den S.Port betrieben. Genau diesen Sensor kann man benutzen, um die Horus Lagesensor Funktion nachzustellen.

Ich habe das eben mal getestet, dabei hat ACCx und ACCy erwartungsgemäß die Erdbeschleunigung angezeigt, also waagrecht 0, senkrecht 9,81 m/s². ACCz geht von -180° bis +180°, nur ist mir nicht klar, wo der GY-521 seinen Nullpunkt für ACCz setzt, das scheint jedesmal woanders zu sein. Kennt jemand diesen Sensor, bzw. das Verhalten bei ACCz?

Falls jemand nachbauen will:
Um im openXsensor die Übertragung von Höhe und VSpeed zu unterbinden, muss man diese Variable in oXs_out_frsky.cpp in irgendetwas ("Varionixda" z.B.) ändern:

// pointer to VSpeed
#if defined(VARIO)
p_measurements[1] = &mainVspeed ;
#else
p_measurements[1] = &no_data ;
#endif

dann werden die Varioroutinen nicht gefunden und nichts übertragen, außer den drei ACC-Werten.

Die Sensoren am TX-internen S-Port, der wie immer bidirektional ist, werden aber nur bei einem aktiven Empfänger gefunden. Die können dann per Input einfach weiterverarbeitet werden um Drehen und Neigen des Senders für irgendwelche Aktionen zu verwenden. Der Arduino verträgt wohl die Senderspannung, ich habe aber sicherheitshalber eine 3,3 V Zenerdiode vorgeschaltet.



GPS würde natürlich noch Sinn machen, aber da wurde in der Horus der serielle Anschluss benutzt. Für die Taranisse gibt es den entsprechenden Code noch nicht. Man könnte zwar auch das GPS über S.Port anschließen, bräuchte dann aber Zugriff auf die GPS-Home-Position. Keine Ahnung, ob das mal funktioniert.

Gruß Bernd

Damit das Ganze nicht so abstrakt ist, habe ich ein kleines Video gedreht. Wenn man die Kanäle 10, 11 und 12 beobachtet, sieht man die Auswirkungen der Lageänderung Nick, Roll und Yaw. Dies kann man zum Steuern beliebiger Funktionen nutzen, einfach indem man den Sender bewegt, oder sich dreht.

[video=youtube_share;55FDD-pvX2I]https://youtu.be/55FDD-pvX2I[/video]



Mstrens habe ich befragt, ob es eine Möglichkeit gibt, Yaw z.B. fest nach Norden auszurichten, um eine absolute Orientierung zu erhalten. Die Antwort war Nein, ist aber so interessant, dass ich sie hier anhänge.


The accelerometers provide signals that are related to the forces applied on the IC.
One of the forces applied to the IC is the gravity. This is even the only one force that applied when you integrate an enlapse time of several second.
If the IC do not move (or at least do not get an extra acceleration) the only force applied is the gravity.
If you put the GY521 flat on a table, the gravity will apply along Z axis. So AccZ will be diferent from 0 ( in fact = 1 g = 9.81 m/sec2) and AccX and AccY will be 0 (or very close to zero).
If you rotate the GY521 by 90 degree putting Z axis horizontally and stop moving, then gravity will apply along X (or Y axis depending how you rotate). So AccX (or Y) will be diferent from 0 ( in fact = 1 g = 9.81 m/sec2) and AccZ and AccY (or X) will be 0 (or very close to zero).
If you rotate the GY521 by 45 degree instead of 90, gravity will apply partly along Z and along X (or Y).
So,we can conclude that when the device does not move, comparing the values of ACC X, Y and Z allows to know pitch and roll orientations.
It is important to note that it is not possible to know the azimuth with accelerometers because if you rotate the device keeping Z axis vertically, none of the Acc values will change.

In practice, it is not safe to calculate the orientation of the device based on the accerometers because the Acc values change when the device is moving , gravity being only one of the forces being applied.

To solve this issue, the device contains also 3 gyroscopes.
Each gyro gives the speed of rotation of the device along each axis. Please note that it is the rotation but the speed of rotation.
In theory, it is possible to calculate the rotation if you integrate (summarize) the speeed of rotation over the time.
Still, this generates a new problem : as the gyro is not perfectly calibrated (returning 0 when device does not move), a minor offset generates a huge error when integration time grows. This is known as the gyro drfit.

To get correct orientation (at least roll and pitch), you have to use a complex algorithm that combine the data from the accelerometers with those from the giro.
The giro data are used to calculate short term changes of orientation and the accelerometer to realign the "calculated gyro orientation" with the gravity vector (averaging on a longer time the accelerometers).

If you want a correct azimut, you need an extra sensor (measuring the magnetic field), in order to realing the "calculated gyro orientation" along North/South. The GY521 does not contain this kind of sensor.

kannst du damit volle 100% Weg einstellen?
Dürftest damit dann weiter als bei der Horus sein, zumindest gehört hab ich noch nichts, das die achsen als eingabe verarbeitet werden. wäre für die TaranisD auf jeden Fall Interessant

Mit dem Scale-Feld in der Input Maske kann man fast alles hinbiegen. Dort wird der Wert eingegeben, der 100% Input ergeben soll. Bei Nick und Roll habe ich dort 10 und bei Yaw 18 stehen und bekomme so für alle 3 Achsen -100 bis +100. Ich kann bloß mein Handgelenk beim Filmen nicht so weit verdrehen

Der Sensor funktioniert einwandfrei, mal sehen, was für Anwendungen kommen. Im Moment kann man schonmal die Taranis als Wasserwaage einsetzen.

Bei der Horus unter FrskyOS ist der Lage Sensor nutzbar, da habe ich letzte Woche schon mit rum gespielt.

schön zu hören. Wobei hierdurch wäre der Vorteil der Horus auch wieder weg, einzige noch nutzbare VOrteil wäre der GPS abstandsmelder zum Modellfinden, und das mach ich am Handy mit Richtungsanzeige. So stirbt meine D wenigstens nicht, da ich schon immer mehr die E nutze

Mit Abstand meinst du die Distanz?
So wie das hier?

jupp genau das

GPS für den Sender ist eigentlich kein Ding, das könnte man am selben Arduino betreiben, ich sehe nur noch keine Möglichkeit, die GPS-home-Position in OpenTX zu ändern. LUA hat darauf wohl keinen Zugriff, aber da bin ich nicht sicher. Und ob die dev´s demnächst das serielle Protokoll wie in der Horus installieren? Im Moment haben Sie wohl andere Baustellen.

Mit einer standalone LUA-Lösung würde es aber funktionieren, wenn LUA auf die beiden GPS zugreifen könnte (die sich nur durch die Sensor-ID unterscheiden). Da kann vielleicht mal ein LUA-Wissender nachschauen.

Das mit den beiden Sensor IDs werde ich am WE mal testen. Mal schauen, ob dann wirklich 2 verschiedene GPS in der Telemetrie auftauchen.

Das GPS in der Horus taucht unter OpenTX 2.2 nicht in der Telemetrie auf, nur unter FrskyOs war es zu sehen.

kann mir vorstellen das es eben noch keinen Wirklichen Praktischen Nutzen hat, Distanz vom Modell ist mit der Startposition zu ermitteln, da braucht es keine Variable Position vom Sender von
Man darf eben nicht vergessen, das Opentx für die Horus immer noch in der Mache ist.
Gutes Beispiel, das nach 1.5 Jahren immer noch keine Praktische Anwendung für das BT gefunden wurde(Tracker ausgenommen)

Den Modellfinder hast du ja schon angesprochen. Und beim Streckenflug (Cross Country) ist es auch sinnvoll, wenn man mit Bordmitteln die Position vom Sender und vom Modell loggen und immer die wahre Distanz sehen kann.

Außerdem würde ich gerne rauskriegen, wann das S.Port Protokoll anfängt zu kot..n, es ist ja Wahnsinn, was da Alles durchgeht.

Hi carbo

um das SPort-Kotzen herauszufinden, gibt es doch das hier : https://www.rcgroups.com/forums/showthread.php?t=2245978
Funktioniert bei mir bestens und wurde kontinuierlich weiterentwickelt. Mal gut beladen, Übertragungsrate erhöhen und mal schauen. Bin gespannt auf einen Feedback.

mfg hw

hw,

über den Thread bin ich schon oft gestolpert, habe aber nie kapiert, um was es da genau geht. Kannst du in 3 Sätzen erklären, was man damit machen kann?

Besser erklären als pawelsky kann ich das nicht, ist alles bestens beschrieben und übersichtlich programmiert. Sich in die Materie vertiefen ist nötig und lesen muss man auch können.
Ist Wochenende - also los. Mit ein paar Stunden solltest Du durchkommen. Auf die Ergebnisse bin ich gespannt - interessiert mich auch.

mfg hw

OK, ich habe verstanden, dass ich damit beliebige Telemetriedaten in das S.Port Protokoll umsetzen kann. Ich habe nicht verstanden, warum ich das wollen sollte und auf welche Ergebnisse du gespannt bist. Ich habe nicht verstanden, was das mit dem Thema hier zu tun hat. Wenn der S.Port das nicht schafft, was ich machen will, helfen mir Pawelskys libraries auch nicht weiter. Wenn er es schafft..........

Hi Carbo

so dramatisch sehe ich das nicht. Mit den Lib's von P kannst Du gezielt einen Datendurchsatz erzeugen und schauen, was im TX ankommt, eventuel mit Logs.Der S.Port schafft schon einiges, wenn ich mich richtig an Versuche erinnere - auch ordentliche Refreshraten, wenn es sein muss. Ausprobieren hilft weiter. Fehlt das Know-How oder der Wille ?

schönen Abend noch

hw

Leider beides und es kommt noch "keine Lust" dazu. Aber das ist ja das Schöne an Communities, dass man sich gegenseitig ergänzen kann.

Aktuell könnte ich Hilfe aus dem Theorielager brauchen, weil Mike Blandford mich darauf hingewiesen hat, dass meine gepollten Daten des TX Sensors auch parallel an den RX gesendet werden. Das hat mich einigermaßen geschockt, weil ich es so nicht erwartet habe.

Link

Da du sicherlich keine "Luftpumpe" bist, kannst du was beitragen?

Der SPort to UART kann ja so wie ich die Anleitungen verstehe auch in beide Richtungen verwendet werden.
Ich bin aber nicht so fit in der Geschichte um selber eine Anwendung damit zu realisieren.
Denkbar ist für mich z.B. eine Erweiterung in der Art der Nautik-Module....( = mehr übertragbare Funktionen )
Ich denke mit der Entwicklung Sensoren auch im Sender einzubauen stehen wir gerade am Anfang dieser Thematik.
Ralf