SONSTIGE MAVLink für OpenTx und Telemetrie Skript

[QuadCrash]

Das andere mögliche(!) Problem ist noch, dass das Crossfire ja einen kleinen Ausschnitt von der empfangenen Mavlink-Telemetrie seinerseits, so weit ich weiss, über den einen sPort-Pin hinten im Schacht an den Sender gibt.

Crossfire gibt dort CRSF aus und OTX nimmt das nativ an (hab ich gestern extra noch bei den OTX-Devs erfragt). Das ist einer der Vorteile vom CF, Modul einstecken, CRSF einstellen und schon hat man die Telemetrie auf der Funke, kann einen VTX steuern oder sonstwas.

Schade eigentlich, da wird seitens TBS groß von serieller Bridge geredet ... naja

Die Definition von "serieller Bridge" bei den bekannten LR RC-Systemen ist nicht die Ausgabe von Daten auf einem Hardwareport sondern der Input, der am Eingang anliegt wird am Ausgang wieder ausgegeben. Beim CF kommt nicht zwangsweise Mavlink raus, sondern das, was am RX eingespeist wird.

 

[Schlonz]

Was mir bei der ganzen Sache absolut schleierhaft ist: hardwareseitig ist eigentlich alles für eine vernünftige Anbindung schon vorhanden, sogar mehrfach. Die Software wäre kein Hexenwerk. Der Bedarf ist auch da, schließlich gibt es deshalb schon zig Ansätze und Workarounds.

Kann da jemand mit den entsprechenden Kontakten nicht mal Trappy (oder wie der bei TBS heißt) und den Rest zusammen bringen?

Im Grund würde es für einen ersten Schritt schon reichen, wenn es eine Option geben würde, die Mavlink-Strecke vom internen Bluetooth-Modul mit 57600 Baud auf die, wohl am Expansion Port anliegende, SIO umzuleiten. Damit wäre schon viel erreicht. Und eigentlich sollte das auch im Interesse von TBS liegen, die vielleicht da so noch gar nicht in ihrer Racer-Verbundenheit daran gedacht haben.

ich habe die Kontakte leider nicht, aber vielleicht ja jemand anderes hier?

Viele Grüße,
Stefan

 

[QuadCrash]

Ich hab schon mit Raphael (aka Trappy) darüber gemailt. Die sind im Moment mit Tango 2, Cloud etc. ziemlich ausgelastet. Und vom Haupt-Kundenkreis (Racer) braucht das niemand ... Da muss man halt ein wenig abwarten, Trappy hat da schon aus der Vergangenheit Sympathien zu.

 

[Schlonz]

Das ist eigentlich fein... TBS unterschätzt da ganz klar, dass das Crossfire ausserhalb des reinen Racerbereichs noch verbreiteter wäre, wenn solche Dinge zu Ende gedacht wären (und nicht nur durch die FPV-Brille )

Und Mavlink nativ an die serielle weiterzuleiten, sind im Code höchstens ein paar Zeilen für eine Menüoption und ein paar Zeilen für die Schnittstelle. Vorhanden ist ja alles.

Ich z.B. fliege ja mit UAVs im technisch-wissenschaftlichen Bereich und habe da in den letzten Jahren Crossfire als zuverlässige Lösung absolut zu schätzen gelernt. Es fehlt halt einfach nur noch ein bisschen Finetuning. Ich habe das bei mir gelöst, aber das ist nicht jedermanns Sache.

Ich verstehe auch nicht, warum Crossfire nicht von Haus aus noch ein paar Telemetriewerte mehr aus dem Mavlink ins CRSF oder sPort übersetzt. Das kann ja eigentlich kein Aufwand sein (Gps, roll/pitch/yaw geht ja auch schon), es fehlen in erster Linie ja nur der aktuelle Flightmode, die rel.Alt und die Statusmessages.

Viele Grüße,
Stefan

 

[QuadCrash]

Schreib TBS an … Wie gesagt, Trappy selbst hat dafür einiges übrig, es muss aber auch alles umgesetzt werden (rein zeitmäßig gesehen).

 

[OlliW]

Die Definition von "serieller Bridge" bei den bekannten LR RC-Systemen ist nicht die Ausgabe von Daten auf einem Hardwareport sondern der Input, der am Eingang anliegt wird am Ausgang wieder ausgegeben. Beim CF kommt nicht zwangsweise Mavlink raus, sondern das, was am RX eingespeist wird.

verstehe ich nicht, zumindest nicht wo der Unterschied zur landläufigen Definition liegt

"serial Bridge" = was am Rx-Pin am RX eingespeist wird kommt beim Tx-Pin beim TX raus, und was am Rx-Pin beim TX eingespeisst wird, kommt beim Tx-Pin am RX raus ...

sei es MAVlink oder was Anderes, was auf der einen Seite reinkommt, kommt auf der Anderen raus... eigentlich schon noch ein einfaches Konzept, scheint mir

Was mir bei der ganzen Sache absolut schleierhaft ist: hardwareseitig ist eigentlich alles für eine vernünftige Anbindung schon vorhanden, sogar mehrfach. Die Software wäre kein Hexenwerk. Der Bedarf ist auch da, schließlich gibt es deshalb schon zig Ansätze und Workarounds.

ich habe da tatsächlich nen bischen Verständnis für. Die Software ist vielleicht kein Hexenwerk in dem Sinne von Raketenwissenschaft, aber das ganze hin-un-her konfiguriere usw umzusetzen ist doch immer mit einiger Programmierarbeit verbunden ... das ist jedenfalls immer das Zeug wovor ich mich am meisten scheue das zu proggen, weil es immer mühselig ist, macht keinen Spass

und dann sind die natürlich sehr Racer orientiert

aber es ist ganz klar sehr schade und etwas traurig dass das nicht einfach geht, auch weil wie du richtig sagst alles da ist. Ich denke mit Ihrem Extension Port hatten die das schon immer im Kopf, aber es gab halt immer was wichtigeres ...

mir scheint das hängt auch stark von uns Nutzern ab ... ich meine, wenn jetzt plötzlich 1000 Emails mit Anfragen bei TBS weil sie doch alle gerne das Mavlink-OpenTx-T16 mit CF nutzen wollen eingehen würde, dann würde das die Sache schon pushen ... aber die 1000 Leute für die 1000 Emails müssen halt erstmal daran Interesse haben ...

 

[OlliW]

der erste Nachbau, mit Erfolg

 

[Schlonz]

Ich habe übrigens mal versucht, das mav2pt von Eric für Crossfire und das yapuu-Script zum Laufen zu bekommen. Es sieht im Moment schon ganz gut aus: Mavlink to FrSky S.Port Passthru Converter for LRS or PX4 Pro

Wenn's jemanden hier interessiert, stelle ich das kleine Howto auch mal hier rein.

Viele Grüße,
Stefan

 

[OlliW]

ähm ... Danke für die Info ... das mag interessant sein aber ist eine völlig andere Baustelle und hat mit dem Thread hier ausser das das Wort MAVLink auch vorkommt nichts zu tun ... thread hijacking

 

[Schlonz]

thread hijacking

Ne Olli, echt nicht. Aber keine Sorge, bin schon raus und weg.

 

[OlliW]

es hat nun wirklich etwas gedauert (Wetter war ja auch wirklich besch...eiden in den letzten Wochen, wenig Zeit zum Testen), aber nun kommt es doch noch, das versprochene Demo-Flugvideo:

 

[OlliW]

mal wieder was Neues zum Thema:

- serial1 (aux) und serial2 (aux2)
- RadioMaster TX16S
- MAvlink Router

 

[QuadCrash]

- MAvlink Router

Kann damit bspw. auf einer TX16S Mavlink auf Aux1 Input sein und auf Aux2 Output?

 

[OlliW]

jo
oder umgekehrt
mittlerweile geht das sogar auch noch zusätlzlich mit dem usb port...

mavlink ist allerdings normalerweise bi-directional, ob input oder output macht dann wenig sinn

 

[OlliW]

und hier das Video zum MAVLink Router

 

[mastersurferde]

Cool. Aber wie kommen jetzt die MAVLINK-Daten zuverlässig zur Funke? Crossfire mit Löten oder gibt´s bereits eine praktikable Lösung mit Sport?

 

[OlliW]

ähm, genauso wie die MAVLink Daten bisher auch zuverlässig zu Ground gekommen sind ... 3DR Telemetry, RFD900, DragonLink, APSync, ESP Wifi Telemetry, OpenHD, ULRS, ....

kenne Crossfire's Entwicklung nicht gut, vor einem Jahr konnte es das noch nicht, vielleicht gab's ja ein Update ... ??

Sport is one-wire und bräuchte daher in jedem Fall spezielle Hardware, und ist demnach entsprechend der Projekt-Ziele "ausgeschlossen" ...

 

[mastersurferde]

ok. Ich dachte nur, dass du mit dem Router auf andere Technologien abzielst. Yaapu arbeitet doch ein einer Passthrough Erweiterung für MAVLINK. Hätte ja sein können, dass hier etwas Hand in Hand läuft.
Gruß

 

[OlliW]

ich verstehe offengesagt nicht was du sagts

es könnte sein dass eine Protokolverwirrung herrscht und was mit dem jeweiligen Protokol geht und nicht geht:

Passthrough und Mavlink haben nichts miteindander zu tun ... sind zwei völlig verschiedene Protokolle .

Natürlich kann man immer von einem Protokol in ein anderes Protokol konvertieren, aber das macht die Protokolle nicht identisch, und insb. sind die Möglichkeiten der Protokolle damit nicht notwendigerweise deckungsgleich.

Die hier vorgestellte Firmwareerweiterung basiert auf "ganz gewöhnlichem echten" MAVlink, ohne irgendwelchen Hampeleien. Hat nichts mit Yappu's Ansatz zu tun und funktioniert auf völlig anderer Basis, nämlich Mavlink und nicht Passthrough. Da die Basis "echtes" Mavlink ist, ist alles auch wie bei "echtem" Mavlink. Der Router ist nichts anders als das man meherere Mavlink Komponenten an mehreren Links verknüpfen kann. Ist z.B. in jedem ArduPilot auch enthalten.

 

[mastersurferde]

Ja, das ist natürlich richtig. Passthrough und Mavlink sind zwei absolut verschiedene Paar Schuhe. Aber wie geschrieben, arbeitet Yaapu an einer Tunnellösung für Mavlink über Passthrough. Da dachte ich, dass Du eventuell an einer Implementierung dieser Tunnellösung an die Schnittstellen deines Routers arbeitest. Ich habe den Fortschritt an der Tunnellösung allerdings schon ewig nicht mehr verfolgt.
Ich hatte den ursprünglichen Sinn des Routers nicht ganz verstanden und war der Meinung, dass der Router mit Daten direkt über den (Frsky-)Empfänger direkt vom FC versorgt werden kann.