TBS Crossfire with arduplane

[Mr.Ombre]

Moin Moin,

nutz jemand TBS Crossfire mit arduplane 4.05 ?
Ich weiß nicht, welches Protokoll ich in ardupilot einstellen soll, denn RCIN funktioniert nicht.
Crossfire Empfänger steht auf CH1=CRSF RX und CH2=CRSF TX
In iNav z.B. konnte man serial Receiver mit CRSF Protokoll einstellen, das finde ich aber in ardupilot nicht.

RC over Mavlink wäre zwar möglich, macht aber Probleme mit dem Gyro vom FC

 

[Schlonz]

Nimm doch einfach simples PPM? Funktioniert mit 12 Kanälen ohne Probleme. Und lass das unsägliche RC over Mavlink aus. Der Sinn hat sich mir noch nie erschlossen und das macht imho mehr Probleme als Nutzen.

Crsf soll bald kommen, ist aber im Moment nur im Dev drin.

 

[QuadCrash]

Ich nutze das mit mehreren Möglichkeiten:

- Crossfire Output auf SBUS eingestellt
- Crossfire Output auf Mavlink eingestellt incl. RC over Mavlink. Funktioniert perfekt, allerdings nur 8 Kanäle
- Crossfire Output auf CRSF eingestellt, derzeit nur im Master enthalten

Arduplane erkennt SBUS, PPM etc. übrigens automatisch, sofern denn der richtige Port verwendet wird. Welche FC hast Du denn im Einsatz?

 

[QuadCrash]

Und lass das unsägliche RC over Mavlink aus. Der Sinn hat sich mir noch nie erschlossen und das macht imho mehr Probleme als Nutzen.

Der Sinn darin ist, dass über ein Protokoll RC und Telemetrie übertragen werden kann. Das ging schon lange vor CRSF und F.Port. Bei entsprechender Konfiguration kann sowohl via Sender als auch GCS-Software gesteuert werden (gleichzeitig!). Das ist auch aktuell ziemlich einzigartig, aber nicht auf Crossfire begrenzt.

 

[Mr.Ombre]

Welche FC hast Du denn im Einsatz?

Ich verwende ein FuriousFPV F-35 Lightning FC mit ChiBios und arduplane 4.05. Sobald ich auf dem RC Eingang an dem FC (M-RX) mavlink1 oder mavlink2 aktiviere, spinnen die gyros auf dem IMU.
Es gibt noch einen weiteren RC Eingang (F-RX), der hat aber zwei verschiedene UARTS (3 für RX und 6 für TX) damit kommt XFire nicht zurecht.

 

[QuadCrash]

Stell am Crossfire RX SBUS auf Output 1 ein und nehme den Eingang F-RX. Das funktioniert auf jeden Fall.

Alternativ kannst Du am Crossfire RX Output 1 und 2 auch auf Mavlink stellen und das Signal in BLE (Serial1) oder M-RX (Serial2) einspeisen. Serial 1 oder 2 dann auf Mavlink einstellen (nicht RCIN) und beim Crossfire RC over Mavlink aktivieren.

 

[Mr.Ombre]

Alternativ kannst Du am Crossfire RX Output 1 und 2 auch auf Mavlink stellen und das Signal in BLE (Serial1) oder M-RX (Serial2) einspeisen. Serial 1 oder 2 dann auf Mavlink einstellen (nicht RCIN) und beim Crossfire RC over Mavlink aktivieren.

Danke, das hatte ich schon rausgefunden. Kommt aber nicht in Frage, da wie du oben beschrieben hast, nur 8 Kanäle übertragen werden. Ich benötige 10

 

[Schlonz]

Der Sinn darin ist, dass über ein Protokoll RC und Telemetrie übertragen werden kann. Das ging schon lange vor CRSF und F.Port. Bei entsprechender Konfiguration kann sowohl via Sender als auch GCS-Software gesteuert werden (gleichzeitig!).

Der technische Hintergrund ist mir sowohl bekannt als auch bewusst. Ich benutze Crossfire seit 2016 auf allem Möglichen und kenne Mavlink leidlich ziemlich gut.

Der praktische Nutzen aber ist beim Crossfire mit seiner Mavlink1-Telemetrie aber faktisch komplett 0. Denn das Ganze ist aktuell beim Crossfire weder zuende gedacht noch richtig umgesetzt. Und übertragen werden die Steuersignale bei Crossfire auch separat von der Telemetrie (und das ist auch sehr gut so), erst beim Empfänger werden die Channels eben nicht als PPM, Sbus oder whatever ausgegeben, sondern als RC Override Mavlink Message übertragen.

Das Einzige, was Du faktisch einsparst, ist ein Kabelchen, dafür aber hast Du technisch gesehen ein Rc-Override-Gefrickel mit nur 8 Kanälen.

 

[QuadCrash]

Kommt aber nicht in Frage, da wie du oben beschrieben hast, nur 8 Kanäle übertragen werden. Ich benötige 10

Na, dann nimm halt die erste Lösung mit SBUS, dann hast Du 12 Kanäle zur Verfügung.

 

[QuadCrash]

@Schlonz, ich verwende halt diese Möglichkeit, damit ich gleichzeitig RC, Telemetrie (auf dem Sender) und SmartAudio (Einstellung VTX via .lua Script oder CF TX) und 'ne GCS verwenden kann. Das funktioniert für meine Ansprüche perfekt. Man muss das nicht so machen, ist nur ein Vorschlag ... aber einer, der funktioniert.

 

[Mr.Ombre]

Die Version 4.0.5 unterstützt derzeit noch kein CRFS Protokoll.
Gibt es denn evtl. eine Beta, die das unterstützt?

 

[QuadCrash]

Ich hab meist "Latest" im Einsatz, dort funktioniert das. Das Protokoll heißt übrigens CRSF, wenn Du später mal was wiederfinden willst, würde ich das auch so schreiben ...

 

[Mr.Ombre]

Danke für den Tipp, habe es getestet und mit der Firmware 4.1.0 funktioniert das CRSF Protokoll.

Als FC habe ich eine Kakute F7 AIO und dafür wird auch eine PX4 Firmware 1.10.1 angeboten und diese habe ich auch erfolgreich mit CRSF getestet.

Jetzt bin ich aber gerade mit Ardupilot warm geworden und weiß so ziemlich genau, an welchen Schrauben ich jetzt drehen muss.
Nun mein Dilemma ist, dass die Ardupilot 4.1.0 noch Entwicklungsstatus hat und nicht zum Fliegen freigegeben ist, so zumindest die Warnung. Aber weder mit der stable 4.0.5 noch beta 4.0.6 wird CRSF unterstützt.

Die PX4 Firmware 1.10.1 ist stable und unterstützt CRSF.

Ich brauche mal einen Rat, was ich machen soll

 

[QuadCrash]

Mit der PX4 Firmware habe ich keine eigene Erfahrung, kann ich Dir also nichts zu sagen. Was ich nutze, habe ich geschrieben.

 

[olex]

Ich würde die 4.1.0 nehmen und damit fliegen. "Nicht freigegeben" heißt noch nicht zu 100% ausgiebig getestet bzw nicht lange genug im Umlauf um sicher zu sein dass die Software keine Probleme enthält... in der Praxis fliegen sehr viele Piloten mit der tagesaktuellen ("master"/"nightly") Version von Ardupilot und haben in aller Regel keine Probleme. Die Warnung ist eher für die Einsatzgebiete relevant wo die Sicherheit vorgeht - sprich alles jenseits vom Hobby-Modellbau.

 

[QuadCrash]

Vielleicht noch 'ne Ergänzung: Latest ist gleich Master und die nehm ich wie geschrieben auch.

 

[Mr.Ombre]

Danke für eure Hilfe, mit der 4.1.0 konnte ich auch alles vollständig einrichten.

Ich bekomme trotzdem noch eine FM beim Start, dass "COMPASS_PRIMARY" Parameter fehlt.
Compass über i2c wurde erkann und ist kalibriert und funktioniert auch.
Kann ich die Meldung in QGroundControll ignorieren? In Mission Planner kommt die FM nicht.