Nach inzwischen knapp einem Jahr Bau- und Entwicklungszeit möchte ich hier unseren 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. Herausgekommen ist ein Kopter mit Pixhawk, INAV, Raspberry PI3, EZ_Wifibroadcast und noch ein paar Extras.
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)
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
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

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 …):
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 :