Baubericht: redundanter Hexakopter für diverse Anwendungen - Arducopter und INAV

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Baubericht: redundanter Hexakopter für diverse Anwendungen - Arducopter und INAV

      Einleitung

      Nach inzwischen knapp einem Jahr Bau- und Entwicklungszeit möchte ich hier meinen Hexakopter, Spitzname "Hugo", als Baubericht vorstellen. Allerdings ist das Ganze nach wie vor ein dynamischer Prozess, d.h. der Kopter wird immer wieder überarbeitet werden.
      Bei Hugo handelt es sich um einen Hexakopter der 5kg-Klasse, der als Besonderheit vollständig sicherheitsredundant aufgebaut ist. Das heißt, das System kann einen singulären Ausfall jedes beliebigen Systems insoweit kompensieren, dass eine sichere Rückkehr und Landung möglich ist. Die Redundanz ist nicht gedacht, die Mission zu Ende zu fliegen. Sie ermöglicht aber immer die sichere Rückkehr bzw. Landung.
      Sein eigentlicher Einsatzzweck ist der Betrieb als Inspektionskopter mit hoher Sicherheit im Außenbereich, auch als "fliegendes Stativ". Hier Aufnahmen mit einer Bestückung mit einer Nex5-Kamera mit kleinem Zoomobjektiv, und eine Aufnahme ohne "Hut" :)



      Wie Hugo den Ausfall des primären Flightcontrollers, also des Pixhawks, abfängt, dazu gibt es natürlich ein Video:



      Dazu ist der Kopter ausgestattet mit:

      • 2 Flightcontroller, einem Pixhawk mit Arducopter und einem SP Racing Pro als Backup mit INAV; beide Controller haben ihr eigenes GPS (jeweils ein uBlox M8N)
      • 2 LiPos 6S parallel, jeweils mit eigenem Strom- und Spannungssensor
      • einem Raspberry Pi3, der neben einigen anderen Aufgaben die Telemetrie der beiden Controller überwacht
      • einer einfachen, diskret aufgebauten und (im Vergleich zu anderen Lösungen in dem Bereich) extrem günstigen Umschaltelektronik (< 30€ + Platine)


      Die Umschaltung erfolgt entweder manuell von der Fernsteuerung aus, oder automatisch, wenn der Pi3 den Abbruch des Telemetrie-Streams am UART zum Pixhawk erkennt und dadurch davon ausgeht, dass der Pixhawk steht (was, nebenbei bemerkt, im regulären Betrieb noch nie passiert ist!). Die Umschaltung ist übrigens selbstverriegelnd, d.h. sie muss am Boden durch Trennung der LiPos wieder zurückgesetzt werden. Der Grund dafür liegt darin, dass wiederholtes Hin- und Herschalten unvorhergesehene Seiteneffekte haben könnte (siehe weiter unten).

      Eine Übersicht der Redundanzen gibt besser die folgende Darstellung:



      Darüber hinaus ist der Kopter mit einigen Besonderheiten ausgestattet:

      • Raspberry Pi3 mit Webserver, vollständiger Companion-Anbindung zum Pixhawk FC, HDMI In für HD-Videoübertragung und Anschlußmöglichkeiten für fast alle denkbare Peripherie
      • Unabhängig von der Videoübertragung wahlweise eine vollständige Langreichweiten-WiFi-Bridge für die beliebige Datenübertragung vom Boden zum Pi
      • Fernsteuerung mit Mavlink-Telemetrie-Kanal (57600 Baud) im UHF-Band (868MHz)
      • HD-Videodownlink per WifiBroadcast mit niedriger Latenz
      • Infrarot-Bakengesteuerte Präzisionslandung IR-Lock (+/- 5-10cm genau)
      • Bodenabstands-Kontrolle über LIDAR (Lightware SF11/c)
      • RTK-GPS mit Emlid REACH
      • variable Nutzlast (Kamera, Wärmebild, Platz für unterschiedliche Sensoren)
      • hochfahrbares Landegestell


      Auf Grund seines Aufbaus und des Einsatzzwecks ist der Kopter allerdings kein Longrun-Performance-Wunder. Er erreicht, je nach Akkubestückung und Nutzlast, Einsatzzeiten zwischen 15 und 20 Minuten. Für seinen Einsatzzweck als Inspektionskopter für industrielle Anwendungen ist dies jedoch in der Regel für einen Einzelflug ausreichend.

      Die Details

      Übersicht

      Zu allererst zwei Schaubilder, die den inneren Aufbau des Systems zeigen, die Konzeption der Stromversorgung und den Aufbau der Telemetrie/Sensorik.



      Basis

      Der Grundaufbau beruht auf einem Hexaframe von quadframe.com, dem Foldable mit 400mm langen 21er Rundrohren, 840mm Motorendiagonalabstand. Das "Foldable" ist allerdings reine Makulatur, denn auch denn die quadframe-Rahmen grundsolide sind, war das Falten bei diesem Rahmen schon immer nicht besonders gut gelöst - 24 Schrauben lassen grüßen. Aber durch die Dimension, die der Kopter inzwischen angenommen hat, ist das Falten sowieso nicht mehr möglich. Der Aufbau sollte aber auch in ähnlicher Form mit anderen Frames ebenso möglich sein, denn hier ist der Aufbau recht Standard.



      Die Motorisierung ist (im Moment noch) als Motoren die T-Motor Antigravity 4006 mit Hobbywing X-Rotor 40 - ESCs und 15"x5 Carbonprops. Die ESCs sitzen außen unter den Motoren, in den Rohren sind Stützelkos. Ob diese wirklich nötig sind, darüber gibt es verschiedene Meinungen, Hugo hat sie drin.

      Ansonsten ist hier im Detail noch das Tarot-Landegestell (bzw. die Mechanik eines der Beine) zu sehen. Die typischen quadframe-Motorhalter sind später mit Kappen abgedeckt, hier mit einer der LEDs in der Mitte. Die Motorgrundplatten sind um ca. 4° nach Innen geneigt. Bei Hugo macht sich diese kleine Neigung bei der Stabilität beim Sinkflug extrem bemerkbar. Offenbar reicht die kleine Winkelung aus, um den Downwash so weit zur Seite zu drücken. Die Effizienzeinbuße dadurch sollte sich dabei extrem in Grenzen halten.



      Bis hierher ist der Hexa-Aufbau völlig unspektakulär.

      Die Elektronik: Pixhawk / Inav / Raspi

      Spannender wird es nun bei der Elektronik.

      Der Backup-Flightcontroller, also der SP Racing F3 (Deluxe, mit Baro) ist quasi im Träger des Raspberry Pi3 "eingebettet". Dazu noch zu sehen sind die 3 UART-Module für den PI. Die Module wurden gestrippt, d.h. die USB-Buchsen entfernt. Es handelt sich dabei um übliche CP2102-Module.



      Im Bild zu sehen ist auch die Barometer-Abdeckung mit schwarzem Schaumstoff. Das auf dem SP Racing befindliche Magnetometer ist stillgelegt, wir verwenden das externe, das im GPS-Dom sitzt.

      Die Wahl des passenden Flight Controllers für das Backup-System ist übrigens alles andere als trivial gewesen. Im Grunde sind fast alle modernen "Plug'Play"-FCs dafür völlig ungeeignet. Da der Backup-Controller grundsätzlich "leer" mitläuft (also seine Befehle an die Motoren ja keine direkte Auswirkung haben, weil die ja vom Haupt-FC gesteuert werden), machen bei fast allen FCs Dinge wie Crash-Erkennung, Auto-Disarm, Landing Detection und ähnliche Nettigkeiten den Einsatz als Backup völlig ungeeignet. INAV auf einem Racercontroller ist dagegen eigentlich perfekt, weil er zwar im entsprechenden Flight Mode alle modernen Gimmicks wie Kompass, GPS und Höhensteuerung hat, dagegen aber im Angle Mode mit entsprechender Config sozusagen (das ist jetzt nicht! negativ gemeint) herrlich unkompliziert genauso primitiv-dämlich ist, wie wir ihn brauchen. Also schalten wir die ganzen höheren Funktionen erst im Fall der Fälle, nämlich bei der Notfall-Umschaltung dazu.
      Das ist auch der Grund für die Selbstverriegelung der Umschaltung. Denn der primäre FC könnte nach erfolgter Umschaltung auf den Backup-FC selbst in einen völlig undefinierten Zustand kommen. Im schlimmsten Fall denkt er, er sei gelandet :) Deshalb geht die Umschaltung immer nur einmal, in eine Richtung.

      Der gesamte Block (Backup-FC / UARTs / Pi3) sieht dann übrigens so aus:



      Der Prototyp der Umschaltelektronik ist diskret aufgebaut. Die Umschaltung selbst erfolgt über Relais, so dass im Fall eines Ausfalls der Umschaltung selbst tatsächlich überhaupt nichts passiert. Die Ausgänge des Pixhawks sind im Ruhezustand einfach auf die ESCs durchgeschleift. Ansonsten befindet sich nur noch ein PWM-Eingang für die Umschaltung per Fernsteuerkanal auf der Platine, und ein bisschen Potentialtrennung durch Optokoppler. Achja, und ein Buzzer-Ausgang, damit es hupen kann.



      Den Schaltplan und Platinenlayout stelle ich bei Bedarf zur Verfügung. Eventuell lasse ich mich bei Bedarf auch dazu breitschlagen, eine kleinserientaugliche SMD-Version zu machen :)

      Eingebaut im Kopter selbst sieht das dann schliesslich so aus (wenn jemand den INAV-Controller sucht, die Micro-USB-Buchse auf dem Foto schaut raus ...):



      Im Bild vorne rechts auch noch zu sehen die Huckepack-Platine des Auvidea B101, die den HDMI-Eingang für den PI3 bereitstellt.

      Noch ein paar Details zum Rest, nämlich die Optik der Infrarotkamera für die IR-Lock Präzisionslandung und das Lightware SF11/c LIDAR:



      Zur Präzisionslandung gibt es auch noch ein kleines Video:




      Die Elektronik: Fernsteuerung / Videoübertragung / WiFi-Bridge

      Die Basisfunktionen von Hugo werden über eine Taranis X9D als Fernsteuerung gesteuert, allerdings in Verbindung mit einem TBS Crossfire als UHF-System im 868MHz-Band. Das Crossfire hat gleich mehrere Vorteile: es hält das 2,4GHz-Band frei, hat einen kompletten bidirektionalen 57600-Baud Mavlink-Kanal für Telemetrie, der per Bluetooth am Boden weitergeleitet werden kann (auf ein Android-Tablet oder ein anderes Gerät), und nebenbei hat es eine Funktion als Funkbake bei Verlust, und speichert die letzten GPS-Koordinaten auf dem Sender.

      Zum Zweiten überträgt der Onboard-PI per EZ-Wifibroadcast und TP-Link TL722N-USB-Sticks unabhängig von allem anderen Video in HD zum Boden (1280x720p). Der Onboard-PI hat als HDMI-Eingang dazu einen B101-Encoder an der Kamera-Schnittstelle. Der B101 funktioniert allerdings nicht mit allen HDMI-Quellen zusammen, er ist da manchmal etwas zickig. Mit einer NEX5 oder einer Canon (XA20 oder 6D) funktioniert es aber.
      Das Broadcast-System hat gegenüber einem UPD- oder RTSP-Stream den großen Vorteil, ACK- und Retransmit-frei zu sein. Sprich: die üblichen Probleme von steigender Latenz bei Video-Übertragungen über lange Wifi-Strecken fallen hier nicht an. Der Groud-PI3 wiederum empfängt diesen Broadcast-Stream und kann ihn auch als Videostream per Boden-Wifi oder UDP-Tethering weiterleiten - oder ihn einfach auf einem Monitor per HDMI mit sehr niedriger Latenz anzeigen.

      Und last but not least hat das System bei Bedarf einen Ubiquity Pico als Longrange-Bridge an Bord. Damit kann eine vollständige TCP/IP-Verbindung vom Boden zum Kopter aufgebaut werden.



      Damit, und in Verbindung mit dem Onboard-RasPi, kann eigentlich alles an Technik oder Sensorik auf dem Kopter installiert bzw. verwendet werden, was von Gewicht und Größe passt und in irgendeiner Form per Wifi, Fast Ethernet, seriell, I2C oder PWM angesteuert werden bzw. kommunizieren kann.

      Hier beispielsweise als Bestückung unsere Wärmebildkamera mit PiP-Realbildfunktion:




      Ausblicke

      Was fehlt noch, bzw. was steht noch an?

      Einiges selbstverständlich :) :

      • Umstellung der Gimbalsteuerung auf den RasPi, um direkt die Gimbalausrichtung zu steuern. Mir schwebt dabei z.B. eine automatische Ausrichtung auf ein Objekt vor.
      • Anderer Gimbalmechanismus mit Z-Achse und Schleifring fest am Kopter.
      • Kopter schlechtwettertauglich machen. Da das aber nur mit definitiv höherem Gewicht möglich ist (Umbau und andere Motoren), hängt das von der zukünftigen Verordnungslage ab, in wie weit wir weiterhin >5kg fliegen können


      Wenn jemand zu obigen Punkten gute Ideen hat, immer her damit :) Vielleicht ist für den einen oder anderen ja etwas Interessantes dabei.

      Viele Grüße,
      Stefan
    • Also falls Du damit meinst, die Gimbalmotoren zu steuern - nein. Das macht bei mir auch ein entsprechender Controller, sprich im Moment Storm32. Ich wollte mir mal den Phobotic anschauen, hat da jemand Erfahrungen damit?

      Aber es ist ja gar kein Problem, via Mavlink die Position des Gimbals zu steuern. Der Gimbalcontroller hängt ja eh am Pixhawk mit dran. Und da habe ich ein paar Ideen dazu, wie z.B. das Ausrichten auf ein Motiv.

      Auf dem Pi3 läuft im Gunde genommen ein normales Jessie, mit Mavproxy und Dronekit. Es ist nur dahingehend modifiziert, dass es die SD-Card readonly mountet, damit man den Kopter ohne umständliches Runterfahren (das ich eh immer vergesse) einfach stromlos machen kann. Da Python aber nicht das Performanteste ist, stelle ich das vielleicht mal um. Aber im Moment tut es, und der Pi3 hat mehr als genug Rechenleistung, dass der da keine Probleme mit hat.

      Viele Grüße,
      Stefan
    • In der Praxis hast Du beim Raspi ja irgendwo eingangsseitig von der Kamera her irgendwo um die 50 oder 60ms Latenz. Je nach Übertragung und kompletten En- und Dekodieren kommt man auf etwa 120-150ms im günstigsten Fall (alles andere ist Marketing-Blahblah, denn auch die Lightbridge hat effektiv nicht weniger). Das Problem bei einer netcat-Übertragung ist aber, dass das nur per "normaler" IP-Verbindung geht. Und da ist das Problem, dass bei schlechten Verbindungen (eben wir bei uns durch die Luft) durch Retransmissions die Latenz leider immer weiter ansteigt. Bis schlimmstenfalls zum mehr oder weniger Stillstand.

      Das ist das Interessante bei bei Wifibroadcast und ähnlichen Ansätzen: da wird tx-seitig einfach kontinuierlich gesendet und der rx sammelt alles ein, was er kriegt. Wenn da was an Datenpaketen verloren gehen, sind sie halt weg und werden nicht neu angefordert. Ergo hat man "nur" Bildaussetzer, aber die Latenz steigt nicht an. Das ist mehr so das Feeling wie bei einer analogen Videoverbindung. Dabei ist dann aber noch Einiges an Rechenleistung nötig, weil da erst tx-seitig die Videodaten zu Paketen gepackt werden, dann eine FEC (forward error correction) dazukommt und der rx die Pakete dann wieder richtig zusammen setzen muss. Merh dazu gibts z.B. auf den Seiten von github.com/bortek/EZ-WifiBroadcast
    • Hallo Stefan,

      erst mal herzlichen Glückwunsch für das tolle Projekt und Danke für das Vorstellen. Folgende Anregungen zur Redundanz:

      1) Allein Überprüfen, ob die Mavlink Herzschläge vom Pix noch vernehmbar sind, ist ein schlechtes Kriterium für die Datenintegrität. Besser wäre, die EKF Stati und VIB-Stati abzufragen.

      2) Hast Du mal versucht, ob man direkt an den PWM-Ausgängen der FCs aussagekräftige Vergleiche ziehen kann. Dann könntest Du 3 unterschiedliche Flightcontroler verbauen und die Logik entscheid sich, falls sie nicht mehr überenstimmen, für die beiden, die die äjhnlichsten Werte liefern. Vermutlich müsste mann die PWM Werte für jeden Kanal über eine kurze zeit Mitteln und dann vergleichen. Wäre spannend, was dabei heraus kommt.

      Eine Frage: Wie (welche Leisuntgs-Elektronik?) hast Du die doppelte Batterieversorgung gegeneinander verriegelt - Du misst ja getrennt Strom und Spannung für jede Batterie

      Gruß Rolf
    • Hallo Rolf,
      vielen Dank!

      Zu Deinen Anregungen:
      Ich überprüfe tatsächlich gar nicht mal Heartbeats, sondern nur den blanken Empfang von mavlink-Paketen vom primären FC. Heartbeats kommen in der Praxis zu langsam. Aber prinzipiell hast Du natürlich recht, deshalb spreche ich ja auch von einer Sicherheits-Redundanz. Eine vollständige Redundanz ist das natürlich nicht. Mit mehreren Systemen und Gewichtung der Ergebnisse ist das etwas ganz anderes. Da würde ich aber erst darüber nachdenken, wenn mich jemand für mehrere Jahre Vollzeit bezahlen würde (Scherz!).

      Aber ich kann sagen, dass es zumindest beim Arducopter mit einem Ergebnisvergleich nicht getan ist. In meinen ersten Versuchen mit parallelen Pixhawks hatte ich immer wieder (und zwar schwer vorhersehbar) den Effekt, dass beim Backup-FC sporadisch z.B. die Crashdetection ansprang. Wahrscheinlich haben sich da kleine Attitude-Toleranzen aufgeschaukelt. Ich habe diese Versuche dann aber auch nicht mehr weiterverfolgt. Ich schätze, dass da eine gewisse Menge Synchronisierungaufwand noch nötig wäre, da der Regelkreis durch die EKF-Filter extrem komplex geworden ist. Deshalb auch der jetzige (funktionierende) Ansatz mit dem "dummdoofen" Racercontroller.

      Zu Deiner Frage: Die Lipos haben jeweils zwar einen eigenen Hall-Sensor, sind sonst aber einfach parallel geschaltet. Wichtig ist, dass man die Lipos zu "festen Pärchen" macht, also immer gemeinsam lädt (also nicht zusammen, sondern jeweils einzeln, aber auf gleichen Ladestand) und nutzt. Sonst wären mir keine Probleme aufgefallen. Ich hatte mal mit einer anderen Lösung mit idealer Diode geliebäugelt, das aber wieder fallen gelassen.

      Viele Grüße,
      Stefan
    • Hallo Stefan,

      Fingadar schrieb:


      Da würde ich aber erst darüber nachdenken, wenn mich jemand für mehrere Jahre Vollzeit bezahlen würde (Scherz!).


      Eigentlich kein Scherz: Mehrere Jahre Vollzeit Bezahlung, dazu Angestellte und Büros. Nach Projektende (unabhängig vom Projektausgang !) fürstliche Übergangsgelder mit hohem Altersruhegeld.
      Wir haben lediglich das falsche Hobby gewählt - statt Modellbauer hätten wir Politiker werden sollen ;)

      Zurück zur Redundanz.

      Klar, vollständige geht nicht. Klasse, dass Du Vergleich der Ausgabewerte - wenn auch mit negativem Ergebnis - mal an 2 Pixhawks probiert hast. Aber Du könntest, da Du schon die Mavlink Frames registrierst, die bereits im arducopter verbaute Redundanz abfragen und die EKF werte kritisch bewerten. Inzwischen ist Paul Riseborough ja dabei, auch noch die Konsistenz von 2 GPS auszuwerten. Damit hättest Du bereits GPS+AHRS+Höhe Sensoren allein durch den Pix überprüft.

      Zur Stromversorgung: Ich fliege den X8 auch meist mit 2 immer parallel betriebenen und gleichgetaktet geladenen Akkus. Einen sich im Flug verbaschiedenden Akku müsste man doch eigentlich am unterschiedlichen Stromfluss erkennen. Der (noch) gesunde Akku müsste deutlich mehr Stromfluss haben als der defekte. Hier könnte man vieleicht mit einem Relais reagieren ? Braucht natürlich schon ein ordentliches Relais.

      Berichte bitte weiter.
      Viele Grüße Rolf
    • Rolf schrieb:

      Klar, vollständige geht nicht. Klasse, dass Du Vergleich der Ausgabewerte - wenn auch mit negativem Ergebnis - mal an 2 Pixhawks probiert hast. Aber Du könntest, da Du schon die Mavlink Frames registrierst, die bereits im arducopter verbaute Redundanz abfragen und die EKF werte kritisch bewerten. Inzwischen ist Paul Riseborough ja dabei, auch noch die Konsistenz von 2 GPS auszuwerten. Damit hättest Du bereits GPS+AHRS+Höhe Sensoren allein durch den Pix überprüft.


      Das ist ein interessanter Ansatz, den ich definitiv weiterverfolgen werde.
      Im Moment hätte ich gerne mit höherer Priorität eine funktionierende Collision Avoidance, vor allem in Flugrichtung und auch im Auto-Mode.

      Die neue Lösung mit der Gewichtung bezüglich der GPSe steht bei mir auf dem Plan, weil ich ja für den Kopter auch ein Reach-RTK habe. Aber da bin ich noch nicht dazugekommen :)

      Rolf schrieb:

      Zur Stromversorgung: Ich fliege den X8 auch meist mit 2 immer parallel betriebenen und gleichgetaktet geladenen Akkus. Einen sich im Flug verbaschiedenden Akku müsste man doch eigentlich am unterschiedlichen Stromfluss erkennen. Der (noch) gesunde Akku müsste deutlich mehr Stromfluss haben als der defekte. Hier könnte man vieleicht mit einem Relais reagieren ? Braucht natürlich schon ein ordentliches Relais.


      Der X2 Hub von Mauch wertet die jeweiligen Stromflüsse der Lipos aus und schaltet ein kleines Relais als Signalausgang, wenn der Strom signifikant abweicht. Ich benutze das nur für das Signalling, also ich warne einfach nur (bzw. mein RasPi). Christian Mauch geht eigentlich nur davon aus, dass einer der beiden LiPos beim Ausfall bzw. Problemen einfach weniger Strom liefert.

      Viele Grüße,
      Stefan

      PS: Fortsetzung folgt
    • Einkaufsliste

      Hier nun die „Einkaufsliste“ des Hexakopters, gegliedert in die einzelnen Funktionsbereiche. Ich schreibe, weil ich danach gefragt wurde, auch die ca.-Preise dazu, die aber natürlich nur Stand heute (April 2017) sind. Das Alles ist natürlich, wie auch der ganze Baubericht, einfach Vorschläge, bzw. ein Bericht, wie ich was gebaut habe – weder verbindliche Anleitung, noch Glaubensbekenntnis &#128578; Selbstverständlich gibt es die diversen Teile z.T. von unterschiedlichen Anbietern, die Links dienen auch nur als Beispiele.

      Der Frame
      Wie gesagt, der Frame ist von quadframe.com, aber ein Tarot sollte auch entsprechend umbaubar sein. Wenn ich irgendwann mal reich bin, nehme ich dafür auch mal eine Rosewhite Tamara &#128578;
      Den Frame habe ich genommen, weil alles auch in Teilen erhältlich und sich leicht modifizieren bzw. nachkaufen lässt.

      Erst mal die Teile von quadframe:

      Das macht für den Basisframe 350€ bislang.

      Der Antrieb

      Der Antrieb also 796€

      Die Elektronik

      Die Elektronik macht in der Summe also ca. 1170€, alles Mögliche an Kleinzeug wie Kabel, Stecker usw. mal aussen vorgelassen. Gute HDMI-Kabel sollte man übrigens preislich dann auch nicht unterschätzen, ich mag besonders diese da, weil sie extrem dünn und leicht sind: globe-flight.de/HDMI-Kabel_1

      Die Stromversorgung

      Das eigentliche PDB ist bei quadframe.com beim Frame enthalten.

      Das macht für die Stromversorgung insgesamt etwa 300€.

      Die Fernsteuerung

      Summe Fernsteuerung: 550€.

      Gesamt soweit
      In der Gesamtsumme kommen wir also bislang auf Materialkosten (ohne Porto, Kleinteile usw.) auf knapp 3150€. Es fehlt dabei das Bodenstations-Equipment (schwer, weil sehr variabel), Ladegerät, Gimbal+Kamera, ganz viel Kleinzeug und natürlich die 3D-gedruckten Teile. Und allem, was ich gerade vergessen habe &#128578;

      Fortsetzung folgt …
    • Negalein schrieb:

      Ist erstmal ein super Projekt!
      Aber der verliert seine Position beim umschalten auf den Slave-FC schon recht weit!

      Wenn ich bei meinem Hexa auf den Slave schalte, sackt er max. 0,5 Meter durch!
      In der Horizontalen bleibt er unverändert!

      Ich verwende Wookong als Master und Naza als Slave.


      Danke :)

      Das in dem Video war nicht einfach umgeschaltet, sondern sozusagen die Härtevariante "Ich klaue dem ersten FC den Strom" :) Da ist ein bisschen Gewurschtel bis zur Stabilisierung nachgesehen, denke ich. Das GPS für den Backup-FC hatte ich erst nach dem Umswitchen manuell dazu geschaltet, d.h. die ersten paar Sekunden war der Backup-FC nur im Althold (oder Atti, wie das bei Euch DJI-lern heisst :) ). Das Ganze sah im Video durch die Perspektive dramatischer aus, als es in der Realität war (zumindest in meiner Erinnerung) und es war mit Absicht an dem Tag auch nicht windstill. Durchsacken tut er eigentlich nie. Wenn ich manuell umschalte, zappelt er in der Regel nur kurz.
      Womit schaltest Du bei Dir um?

      Viele Grüße,
      Stefan