LUA für Pixhawk/AUAV-X2 und Taranis
- Themenstarter Jace25
- Beginndatum
Ich schicke heute Abend mal ein Screenshot welche Sensoren (also welche Mavlink-Werte) alle über das Auto-Discovery via S-Port erkannt werden... ist auf jeden Fall beeindruckend und über 1 Dutzend. Man geht dann auf der Taranis einfach ins Telemetry Menü und kann dort entweder manuell Sensoren hinzufügen oder einfach sagen "Auto-Discovery".... die Funke hört dann einfach hin welche Datenfelder alle durch den Pixhawk gefüttert wurden und schlüsselt die auf... sehr fett!
))))))) - vorab besten Dank!!!!
So, auf die schnelle mit ein paar Hinweisen und Einschränkungen
https://github.com/Jace25/LUA-Taranis-Pixhawk/tree/master/SCRIPTS/TELEMETRY
Ich hab es nur mit dem D8R getestet, D4R hole ich in Kürze nach.
Ich hab noch keinen schönen Weg gefunden, wie man an die Sensoren kommt, wenn man sie nicht direkt per ID ansprechen will. Ihr müsst zuerst in den Telemetrie Einstellungen des jeweiligen Modells "detect sensors" machen. Das listet euch dann alle Sensoren auf.
Folgende Sensoren nutze ich, bei mir gab es nur bei Temp Probleme
VFAS -> Lipo Spannung
Alt -> Höhe
Curr -> Verbrauch aktuell
Tem1 (den hat er als Temp gefunden, und er muss auf Tem1 unbenannt werden) -> Flightmode
Temp -> GPSFix
RSSI -> ...
Die Sensoren bei euch müssen so heißen (exakt, case sensitive), da ich Sie mit dem Namen anspreche. Ich überlege noch, ob hier die ID besser ist, aber da ich nicht weiß, ob die IDs sich nicht mal ändern (D4R, D8R) erstmal so. Solange der Name genutzt wird, sollte das Ding mit allen D* Receivern laufen.
Alle oben genannten Sensoren müssen Rohdaten liefern (geht am besten mit Companion einzustellen), danach das Script in SCRIPTS/TELEMETRY kopieren und im TelemtrieScreen des jeweiligen Modells auswählen.
Ich bin gespannt, ob es bei euch funktioniert. Allein der Overhead, der benötigt wird, damit das Ding unter 2.1 läuft, macht mir die Sache echt madig.
Einschränkungen:
Derzeit geht sowohl Gesamtverbrauch als auch Distanz nicht. Das waren beides FrSky interne Funktionen und ich hab sie unter 2.1 noch nicht gefunden.
https://github.com/Jace25/LUA-Taranis-Pixhawk/tree/master/SCRIPTS/TELEMETRY
Ich hab es nur mit dem D8R getestet, D4R hole ich in Kürze nach.
Ich hab noch keinen schönen Weg gefunden, wie man an die Sensoren kommt, wenn man sie nicht direkt per ID ansprechen will. Ihr müsst zuerst in den Telemetrie Einstellungen des jeweiligen Modells "detect sensors" machen. Das listet euch dann alle Sensoren auf.
Folgende Sensoren nutze ich, bei mir gab es nur bei Temp Probleme
VFAS -> Lipo Spannung
Alt -> Höhe
Curr -> Verbrauch aktuell
Tem1 (den hat er als Temp gefunden, und er muss auf Tem1 unbenannt werden) -> Flightmode
Temp -> GPSFix
RSSI -> ...
Die Sensoren bei euch müssen so heißen (exakt, case sensitive), da ich Sie mit dem Namen anspreche. Ich überlege noch, ob hier die ID besser ist, aber da ich nicht weiß, ob die IDs sich nicht mal ändern (D4R, D8R) erstmal so. Solange der Name genutzt wird, sollte das Ding mit allen D* Receivern laufen.
Alle oben genannten Sensoren müssen Rohdaten liefern (geht am besten mit Companion einzustellen), danach das Script in SCRIPTS/TELEMETRY kopieren und im TelemtrieScreen des jeweiligen Modells auswählen.
Ich bin gespannt, ob es bei euch funktioniert. Allein der Overhead, der benötigt wird, damit das Ding unter 2.1 läuft, macht mir die Sache echt madig.
Einschränkungen:
Derzeit geht sowohl Gesamtverbrauch als auch Distanz nicht. Das waren beides FrSky interne Funktionen und ich hab sie unter 2.1 noch nicht gefunden.
Gute Neuigkeiten...scheint auch mit den X-Receivern zu gehen! =) Grad mal mit einem X8R ausprobiert und zumindest RSSI und Flightmode kommen sauber rüber! =) ... alles andere konnte ich noch nicht testen, da der Pixhawk nackig auf dem Schreibtisch liegt und nur via USB betrieben wurde.
Da sich alles an den Namen der Sensoren festmacht ist das ja auch kein Wunder =) Vorausgesetzt die sind richtig benannt, kann das Skript die Werte abgreifen! (Ich musste übrigens auch Temp in Tem1 umbenennen).
TOP!!!!!!
Da sich alles an den Namen der Sensoren festmacht ist das ja auch kein Wunder =) Vorausgesetzt die sind richtig benannt, kann das Skript die Werte abgreifen! (Ich musste übrigens auch Temp in Tem1 umbenennen).
TOP!!!!!!
Stimmt, da das in der Taranis jetzt vereinheitlicht wurde, müssten x receiver auch gehen. Immerhin ein netter Nebeneffekt.
Ich hatte gehofft, das d4r und d8r dieselben sensorids nutzen und ich die Sensoren im finalen Entwurf dann per ID ansprechen kann um so den schritt mit der Benennung zu sparen. Offenbar führt da aber kein weg dran vorbei. Mein d4r geht auch erst dann, wenn ich die Sensoren erkannt und richtig benannt hab.
Ich hatte gehofft, das d4r und d8r dieselben sensorids nutzen und ich die Sensoren im finalen Entwurf dann per ID ansprechen kann um so den schritt mit der Benennung zu sparen. Offenbar führt da aber kein weg dran vorbei. Mein d4r geht auch erst dann, wenn ich die Sensoren erkannt und richtig benannt hab.
Moin Jace,
Ja, das ist wirklich super! Der Schritt mit dem "Auto-Discover new Sensors" ist ja in 2.1.x sehr schön gelöst.... dass die FrSky Empfänger natürlich mit zwei "Temp" Sensoren daherkommen ist unschön aber durch Umbenennung leicht zu lösen. =)
Bei mir findet der locker ein Dutzend Sensoren beim Autodiscover.... wäre cool, wenn wir die alle irgendwie dargestellt bekämen.
Sollten ja jeweils dieselben Sensoren sein, da der Datenstream vom APM/Pixhawk standadisiert ist.
Ja, das ist wirklich super! Der Schritt mit dem "Auto-Discover new Sensors" ist ja in 2.1.x sehr schön gelöst.... dass die FrSky Empfänger natürlich mit zwei "Temp" Sensoren daherkommen ist unschön aber durch Umbenennung leicht zu lösen. =)
Bei mir findet der locker ein Dutzend Sensoren beim Autodiscover.... wäre cool, wenn wir die alle irgendwie dargestellt bekämen.
Sollten ja jeweils dieselben Sensoren sein, da der Datenstream vom APM/Pixhawk standadisiert ist.
Schade ist, dass diese Lösung (ich nenne sie mal die "native Pixhawk Lösung") andere Parameter Ausspuckt als die Lösung mit dem Teensy Wandler. Hier sind z.B. auch Telemetriewerte für AccX, AccY, AccZ vorhanden --- super Indikatoren, wie viel Vibration auf dem Rahmen ist und ein Anhaltspunkt, ob man Rolling Shutter bekommt oder nicht ;-)
Ob man die Paramater die der Pixhawk bei der nativen Lösung sendet noch am Pixhawk beeinflussen kann?
Ob man die Paramater die der Pixhawk bei der nativen Lösung sendet noch am Pixhawk beeinflussen kann?
Ich hab seit längerem vor, mal einen meiner Copter auf nen x Receiver umzubauen (16 Kanäle). Bislang hab ich das nicht gemacht, daher kann ich hier leider auch nichts entwickeln. Den Simulator für die Telemetrie habe ich noch nicht soweit durchschaut, dass ich mit dem neuen Telemetrie-System alle Daten simulieren kann.
Generell sollte das Möglich sein, Daten nur dann anzuzeigen, wenn Sie auch kommen. Bis auf Distanz und Verbrauch seit Start sind alle von den D-Serie gesendeten bzw. sinnvollen Werte im Screen eingebaut.
Die D Serie sendet noch die Spannung mit, die am Empfänger anliegt (5-6V), bringt aber niemandem was, zumal es noch die echte Lipo Spannung gibt und die Spannung am Empfänger sich eher nicht ändern wird.
Wenn ich mir mal nen X Empfänger kaufe, passe ich das an und baue einen 2. Telemetrie-Screen (wenn ich bis dahin herausgefunden habe, wie ich das Simuliere. So ist es derzeit echt extrem nervig. Man ändert 5 Zeilen Code, muss die Taranis im USB Modus anschließen, das Script ändern, die Taranis ohne USB booten, den Telemetrie-Screen aufrufen und sieht erst dann, ob alles Korrekt ist).
Generell sollte das Möglich sein, Daten nur dann anzuzeigen, wenn Sie auch kommen. Bis auf Distanz und Verbrauch seit Start sind alle von den D-Serie gesendeten bzw. sinnvollen Werte im Screen eingebaut.
Die D Serie sendet noch die Spannung mit, die am Empfänger anliegt (5-6V), bringt aber niemandem was, zumal es noch die echte Lipo Spannung gibt und die Spannung am Empfänger sich eher nicht ändern wird.
Wenn ich mir mal nen X Empfänger kaufe, passe ich das an und baue einen 2. Telemetrie-Screen (wenn ich bis dahin herausgefunden habe, wie ich das Simuliere. So ist es derzeit echt extrem nervig. Man ändert 5 Zeilen Code, muss die Taranis im USB Modus anschließen, das Script ändern, die Taranis ohne USB booten, den Telemetrie-Screen aufrufen und sieht erst dann, ob alles Korrekt ist).
Ich habe gestern das Script leicht aktualisiert und eine Anleitung ins Github gepostet. Aus meinem ersten echten Flugtest ist dann leider nichts geworden. Fliegt jemand von euch damit schon?
Ich denke die Berechnung der Entfernung werde ich erst in weiter Zukunft einbauen, das kommt als Formatierte String mit Minuten Sekunden und Grad Zeichen, Lat und Lng zusammen. Ich muss den String zerlegen, und daraus dann mit den einzelnen Werten rechnen. Das mache ich mal irgendwann in Ruhe ;-)
Falls ihr ansonsten zufrieden seid, freue ich mich, wenn ihr mich und den Beitrag positiv bewertet ;-)
Ich denke die Berechnung der Entfernung werde ich erst in weiter Zukunft einbauen, das kommt als Formatierte String mit Minuten Sekunden und Grad Zeichen, Lat und Lng zusammen. Ich muss den String zerlegen, und daraus dann mit den einzelnen Werten rechnen. Das mache ich mal irgendwann in Ruhe ;-)
Falls ihr ansonsten zufrieden seid, freue ich mich, wenn ihr mich und den Beitrag positiv bewertet ;-)
Goil!!! Gleich heute Abend mal ausprobieren.... ja, mit der ersten Alpha-Version von dir bin ich schon geflogen... RSSI und Flugstatus kamen einwandfrei rein... Akku und GPS habe ich nicht drauf geachtet.....werde ich aber nachholen.... (war der Erstflug von einem neuen Kopter.... da guckt mal verständlicherweise eher auf den Kopter als auf die Funke!!!!!).....
Bin auf jeden Fall gespannt was da noch so kommt von dir!!! Ist geil das Skript!!
Bin auf jeden Fall gespannt was da noch so kommt von dir!!! Ist geil das Skript!!
