Kopplung Crossfire (Mavlink) und RaspberryPi für Routing

    • Kopplung Crossfire (Mavlink) und RaspberryPi für Routing

      Wie ich gerade testet habe, lässt sich die Mavlink-Telemetrie der TBS Crossfire auch an ein einen kleinen Raspberry Pi binden. Damit lässt sich mit einfachen Mitteln ein Mavlink-Router aufbauen. Ich werde damit in die Bodenstation Tablet und einen Antennentracker über das bodengebundene (W)Lan einrichten.

      Basis
      Als Basis dient zum Test ein normales RASPBIAN STRETCH LITE als Image. Nach dem üblichen Aufspielen des Image auf SD und erstem Boot nicht vergessen, "gesamte Platte nutzen" und SSH freigeben. Passiert mir dauernd ;)

      Bluetooth-Setup
      sudo apt-get install bluetooth bluez blueman

      Dann mal sicherheitshalber neu starten:
      sudo reboot

      Dann folgt die Bluetooth-Einrichtung
      sudo bluetoothctl

      Auf der Kommandozeile der bluetoothctl kommt das Pairing:


      Quellcode

      1. agent on
      2. default-agent
      3. scan on
      4. pair xx:xx:xx:xx:xx (das ist im Folgenden immer die Device id der Crossfire)
      5. trust xx:xx:xx:xx:xx
      6. connect xx:xx:xx:xx:xx
      Beim Scan sollte die Crossfire mit ihrer ID zu sehen sein.

      Mavproxy installieren

      (Mavproxy ist vielleicht nicht unbedingt der geeignetste Proxy, da er als Python-Script enorm viel Rechenleistung verschwendet. Hier wäre cmavnode oder mavlink-routerd besser geeignet. Darum kümmere ich mich aber später einmal, mavproxy ist zum Test das robusteste.
      sudo pip install MAVProxy
      Eventuell bei den üblichen Mavlink-Python-Zickereien (falls da wieder etwas nicht gefunden wird): sudo apt-get install libxslt-dev

      Einrichten des Com-Ports

      sudo rfcomm bind 0 xx:xx:xx:xx:xx:xx

      Start von mavproxy für erste Tests

      sudo /usr/local/bin/mavproxy.py --master=/dev/rfcomm0 --baudrate=57600 --out=udpbcast:192.168.0.255:14550
      Die IP natürlich auf die eigene lokale Broadcast im Netz anpassen.

      Lösen des Com-Ports

      sudo rfcomm release 0


      Das war erstmal ein erster Test. Im lokalen Netz ist es so problemlos möglich, per UPD über den mavlink-Proxy via Crossfire auf die Pixhawk-Telemetrie des Onboard-Pixhawks zuzugreifen.

      Weiteres folgt, falls jemand hier Interesse daran hat :)

      Viele Grüße,
      Stefan
    • Klasse Idee und gute Beschreibung.

      Ohne den Thread mit einer anderen Lösung kapern zu wollen, doch zufällig habe ich vorhin eine weitere Möglkchkeit gefunden, noch eine Bodenstation (zB Antennentracker) über WLAN anzubinden.

      Der Missionplanner kann Mavlinkdaten weiterreichen: Dazu STRG-F drücken, im dann geöffneten Temp-Fenster Mavlink anklicken und dann im nöchsten kleinen Fesnter die Art der Verbindung auswählen. Habe das vorhin erfolgreich mit dem Laptop, das über USB mit dem Crossfire verbunden ist und über WLAN im Heimnetzwerk angemeldet ist, erfolgreich probiert (Laptop als TCP Server). Mit Tower auf dem Androidhandy konnte ich mich dann ebenfalls als Bodenstation "einklinken". Am MP kann man sogar einstellen, ob die weitere Bodenstation nur "Hören" oder auch "Senden" darf.
    • Danke Rolf.

      Was für mich gegen die Variante mit der Mavlink-Weiterleitung über den MP spricht, sind ganz profane, praktische Gründe:
      • Ich habe nicht immer etwas dabei, auf dem ein Mission Planner auch läuft
      • Und selbst wenn, dann habe ich den Odys oder Laptop in der Regel nicht gerade in bluetooth-tauglicher Nähe von der Taranis. Ich bin bekennender "Herumläufer", der seine Freiheit braucht :)
      Einen kleinen Pi bekomme ich problemlos räumlich mit an die Taranis bzw. ans Tablet drüber. Ein WLan am Boden habe ich eh, und eine Bodenstation in der Regel auch. Auf der sitzt dann der Tracker, und der Videoempfänger. Der Raspi soll dann die Telemetrie dann einfach an die Bodenstation weiterleiten, die dann auch mal 20 oder 30m entfernt sein kann.
      Und von dem aus kann ich dann das Videosignal auch wunderbar weiter verteilen. So bekomme ich dann beispielsweise das Videosignal parallel per RTSP mit akzeptabler Latenz wieder aufs Tablet, auf den Zuschauermonitor und wo ich es noch brauche.

      Viele Grüße,
      Stefan
    • Hallo Stafan,

      die "Bodenmobilität" hatte ich so noch garnicht bedacht (War bei dem Wetter eher gedanklich dabei, im warmen Wagen am Laptop mit Joystick sitzen und TBS TX draussen hoch montiert).

      Die Raspberry-Variante ist natürlich besser, allein was die Reichweite am Boden per WLAN angeht - und man muss nicht immer alles rumschleppen.

      Um mit der Taranis sich ausserhalb der BT-tauglichen Entfernung zu bewegen: Crossfire Tx + Raspberry fix am "Sendeturm" (oder noch weiter gesponnen: Crossfire Tx auch mit auf dem Antennentracker mit Richtantenne) . Von der Taranis zur Ctossfire Tx per normaler 2,4 GHZ Verbindung an einen kleinen Frsky Empfänger, der PPM an den Corssfire-Eingang abgibt.

      Erst mal so ins unreine gedacht.

      LG Rolf
    • Rolf schrieb:

      Von der Taranis zur Ctossfire Tx per normaler 2,4 GHZ Verbindung an einen kleinen Frsky Empfänger, der PPM an den Corssfire-Eingang abgibt.
      Hmmm... geht das? Gibt es darüber irgendwelche Berichte bzw. Erfahrungen? Ich dachte immer, dass die Crossfire mit der Taranis über ein spezielles Protokoll kommuniziert?

      Oma der Bruchpilot schrieb:

      und mit dem Raspberry gibts eine andere leichtere Wariante mit der Pix2.1 Pro und dem Intelboard Pix2.1 Pro
      intel edison modul
      Das hat aber nichts mit meiner Bastelei zu tun, denn ich will den Pi ja nicht am Pix in der Luft haben. Ich werde ja einen Pi als Mavlink-Router am Boden einsetzen, um die Telemetrie, die vom Pix über die Crossfire zum Boden gesandt wird, auf mehrere Links am Boden zu verteilen. Ich möchte u.a. auch versuchen, ob ich damit den RTK-Korrekturstream darüber zum Kopter hochbekomme, dann könnte ich mir endgültig auch am Hexa die WLAN-Strecke nach oben sparen. Kostet alles Gewicht und Strom :)

      Btw. der Edison ist leider von Intel abgekündigt und wird nicht mehr produziert. Da gibt es nur noch Restbestände (wenn überhaupt). Deshalb ist der Pix2.1pro mit dem Edison-Carrier eigentlich obsolet. Es gibt erste Entwürfe für die Kombination aus Cube und Pi-Compute Module, aber das dauert noch.

      Viele Grüße,
      Stefan
    • Hallo Stefan,

      Fingadar schrieb:

      Hmmm... geht das? Gibt es darüber irgendwelche Berichte bzw. Erfahrungen? Ich dachte immer, dass die Crossfire mit der Taranis über ein spezielles Protokoll kommuniziert?

      Müsste bestimmt gehen. Habe mir gerade einen 8 Kanal Frsky D8 mit PPM Augang bestellt. Allerdings hat man so natürlich keine Telemetrydaten auf der Taranis und bräuchte einen kleinen Androiden oä auf der Taranis montiert.

      LG Rolf
    • Hallo Stefan,

      den Crossfire habe ich schon mal per BT mit dem Rasp. erkannt :)

      Mit dem raspbian stretch light vom 27.11.17 kriege ich leider Mavproxy nicht ans laufen (Liegt sicher an mir, bewege mich in Linux noch bar jeglicher "situational awareness")

      Ich lade wohl mal ein APSync-Image ardupilot.org/dev/docs/raspberry-pi-via-mavlink.html
      damit habe ich erfolgreich einen Companion - Pi3 an den Pixhawk angebunden und mavproxy läuft da ja auch drauf.

      Zu Deiner Idee mit dem "freien herumlaufen" am Boden: eigentlich müsste man ja einen Teensy mit Mavlink->Frsky-S.Port Umsetzer ebenfalls an den Raspberry klemmen können ?

      Auf dem Raspberry müsste dann das Mavproxy so parametrisiert sein, dass es die Bluetooth Verbindung zum Crossfire TX nicht nur im (bodengebundenen) WLAN zur Verfügung stellt, sondern die Daten (senden würde ja reichen) auch über einen UART an den Teensy weitergibt, der wiederum die dort programmierten Variablen an den Frsky-Empfänger schickt und damit zur Taranis.

      LG Rolf
    • Kopplung Crossfire (Mavlink) und RaspberryPi für Routing

      Wenn Du mir verrätst, was genau das Problem mit dem Mavproxy ist, kann ich vielleicht helfen. Denn ich habe letzte Woche den Mavproxy genau auf Stretch installiert.

      Die Frsky-Idee müsste von der Mavlink-Seite her funktionieren. Allerdings kenne ich mich mit Frsky-S.Port nur ganz rudimentär aus und kann da nicht viel dazu sagen. Meine S.Port-Erfahrungen beschränken sich auf einmal ein Lua-Script für meine kleine Inav-Robokatze gebaut...

      Ich plane, die Crossfire an der Taranis zu lassen, BT über einen kleinen Pi0W abzugreifen, der dann zum einen Mavlink per Wlan weitergibt, und als OTG-Device per USB mit am Tablet hängt, Mavlink darüber ans Tablet gibt und damit auch versorgt wird. Theoretisch alles kein Problem, mal sehen, ob das auch praktisch funktioniert :)

      Viele Grüße,
      Stefan
    • Mit dem APSync-Image vom 05.10.17: firmware.ap.ardupilot.org/Companion/apsync/
      läuft Mavproxy - ist bereits vorinstalliert. Einwahl ins heimische Netz klappt, bluetoothctl ist auch drauf.

      Fehlt noch was Zeit ;)

      Gruß Rolf

      Nachtrag - durch Probleme (mal lief SSH mal nicht über WLAN) - ist mir erst aufgefallen, dass das vorinstallierte Image bereits einen Accespoint auf dem Pi3 zur Verfügung stellt.
      WLANName: Ardupilot, PW: ardupilot, ssh nach 10.0.1.128 , Login mit apsync/apsync oder pi/raspberry

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Rolf ()

    • Ich berichte mal weiter von den "Versuchen" mit dem Arduplane Image auf dem pi3:

      Bluetoothverbindung zum CF klappt, seriellen Port einrichten auch, Mavlink verbindet sich auch zum Kopter *Freu* und Danke an Stefan.


      Eine Clientstation konnte ich auch anbinden, aber leider keine zwei - egal ob
      --out=udpbcast:10.0.1.255:14550 (da funktioniert alles, aber nur mit einer Groundcontrolstation)
      --out=udp:10.0.1.255:14550 oder --out=udpin:10.0.1.255:14550 ebenso oder garkeine Verbindung


      (Beim nächsten Test bleibt eigentlich nur noch --out=udpin:0.0.0.0:14550 zu versuchen ?)

      Falls nicht bekannt, hier weiteres zu Mavproxy: ardupilot.github.io/MAVProxy/html/index.html



      Ansonsten sind 2 Webserver vorinstalliert, einer auf dem üblichen HTTP Port 80:



      Mit netten Funktionen (alles funktioniert zwar noch nicht, aber mal per Web auf den Kopter zugreifen ist auch ein Gag)



      Auf dem Port 8000 befindet sich ein weiterer Server,



      mit dem eine evtl. am Pi angeschlossene Kamera gestreamt werden kann.


      LG Rolf
    • Bisschen Zeit gefunden habe, weiter zu machen:

      Mavproxy gibt an mehrere Groundstations die Mavlink-Daten weiter, wenn man entsprechend Ausgänge beim Aufruf angibt:

      also zwei mal out mit unterschiedlichen Ports: zB
      --out=udpbcast:10.0.1.255:14550 --out=udpbcast:10.0.1.255:14551

      Der kleine Testkopter, der jetzt den kleinen Crossfire Empfänger hat, hatte vorher einen FrSky X4RSB, der beim üblichen Binden mit der Taranis auf D16 lediglich einen SBUS Ausgang hat.
      Wer die Anleitung mal liest, ist klar im Vorteil : Bindet man den kleinen Empfänger mit Ausgang 2 und 3 verbunden, schikt er auf Ausgang 1 Kanal 1-8 per PPM raus.

      Gerade mal am Crossfire TX angeschlossen, erkennt Crossfire sofort PPM8 :)

      Da ich das Crossfire am Tracker haben möchte, ist das schon mal ein guter Schritt weiter:
      Taranis -> Frsky x4RSB am Crossfire TX <- 868 MHZ -> Plane/Copter
      Der X$RSB hat S.Port Telemetrie, wie schon mal geschrieben, will ich dort dann aus den Mavlink-Daten zur Not mit einem Teensy die Telemetrie für die Taranis einspeisen. für die Groundstations wird am Tracker über lokales WiFi die Telemetrie weitergereicht.

      Gruß Rolf
    • Am RCin Eingang mit einem der beiligenden Kabel mit freiem weiß, rot, schwarz farbigen Kabel. Kann eigentlich nur weiß=Signal bedeuten, Spannung zwischen Schwarz (kann ja nur GND sein) und rot ist nicht zu messen (Schade, der Empfänger könnte so über die ext. notwendige Stromversorgun des TX erfolgen) also nur GND und Signal miteinander verbunden und den X4 separat mit Strom versorgt.

      Ob die Pulsezeiten stimmen, die der Frsky rausschmeisst,und ob 12 Kanäle möglich sind, muss ich alles noch probieren, sobald ich was Zeit finde. Bei dem miesen Wetter könnte das am WE sein ;)

      Viele Grüße
      Rolf