Zum Inhalt wechseln


Foto

Baubericht: redundanter Hexakopter mit Pixhawk und INAV

eigenbau multicopter pixhawk redundant hexakopter

  • Bitte melde dich an um zu Antworten
26 Antworten in diesem Thema

#1 fingadar

fingadar
  • 532 Beiträge
  • OrtObernburg am Main
  • Hexakopter mit redundantem Pixhawk/Arducopter und RasPi3 Companion
    EZ-WifiBroadcast mit Auvidea HDMI-In
    FLIR Vue Pro R 640
    Lightware SF11 Lidar
    IR-Lock Precision Landing
    Emlid REACH RTK

Geschrieben 14. April 2017 - 17:51

Einleitung
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.

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“ 🙂

Angehängte Datei  _MG_4772_1500px.jpg   217,94K   4 Mal heruntergeladenAngehängte Datei  _MG_4759_1500px.jpg   215,04K   3 Mal heruntergeladenAngehängte Datei  _MG_4775_1500px.jpg   530,48K   3 Mal heruntergeladen

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:

Angehängte Datei  Ausfalltabelle.png   395,64K   2 Mal heruntergeladen

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.

Angehängte Datei  Sensors_Telemetry.png   162,11K   4 Mal heruntergeladenAngehängte Datei  Power.png   133,58K   2 Mal heruntergeladen

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.

 

Angehängte Datei  _MG_1338_1500px.jpg   351,52K   4 Mal heruntergeladenAngehängte Datei  _MG_1383_1500px.jpg   597,79K   4 Mal heruntergeladen

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.

Angehängte Datei  IMG_1410_1500px.jpg   382,54K   5 Mal heruntergeladenAngehängte Datei  _MG_4765_1500px.jpg   272,26K   4 Mal heruntergeladen

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.

Angehängte Datei  IMG_0142_fullHD_1500px.jpg   686,15K   4 Mal heruntergeladenAngehängte Datei  IMG_0147_1500px.jpg   915,66K   4 Mal heruntergeladen

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:

Angehängte Datei  IMG_0152_fullHD_1500px.jpg   607,13K   4 Mal heruntergeladenAngehängte Datei  IMG_0155_1500px.jpg   236,29K   3 Mal heruntergeladen

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.

Angehängte Datei  IMG_0159_fullHD_1500px.jpg   478,39K   3 Mal heruntergeladen

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

Angehängte Datei  _MG_4780_1500px.jpg   455,66K   5 Mal heruntergeladenAngehängte Datei  _MG_4793_1500px.jpg   528,14K   2 Mal heruntergeladen

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:

Angehängte Datei  _MG_4764_1500px.jpg   391,52K   4 Mal heruntergeladenAngehängte Datei  _MG_4752_1500px.jpg   375,39K   3 Mal heruntergeladen

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.

Angehängte Datei  _MG_4768_1500px.jpg   304,84K   5 Mal heruntergeladenAngehängte Datei  _MG_4769_1500px.jpg   244,14K   6 Mal heruntergeladen

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:

Angehängte Datei  IMG_3064_1500px.jpg   569,99K   5 Mal heruntergeladenAngehängte Datei  IMG_3078_1500px.jpg   655,55K   7 Mal heruntergeladen

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 findet jemand den Bericht hier ja ein wenig interessant.

 

Viele Grüße, Stefan


  • platy, vodoo, Ach-Mett und 7 anderen gefällt das

#2 339427

339427
  • 1.365 Beiträge

Geschrieben 14. April 2017 - 18:48

Cooles Projekt!

Lidar steht auch noch auf meiner Wunschliste. Auch die Videoübertragung per Pi und WLAN ist interessant. Verwendest Du eine Pi Cam oder einen A/D Wandler?

#3 el Kopto

el Kopto
  • 1.689 Beiträge
  • OrtNorddeutschland
  • Hexa / Matrice 100 hybrid mod / Jordana Endurance mit N3 + LB2 + PulseKraft PWM Erweiterung

Geschrieben 14. April 2017 - 21:13

Beeindruckend - in dem Projekt stecken sicher eine Menge Recherche, Tüftelei und Nerven!

 

Ich hätte da so einige Ideen zur Gewichtseinsparung - allerdings würden wir dann wieder in eine Plattform-Diskussion geraten, die Du an dieser Stelle vermutlich nicht haben möchtest.

 

Gut finde ich insbesondere die Umschalt-Platine. Für unsere Österreicher Kollegen sicherlich eine interessante Alternative.

 

Gewisse Bedenken hätte ich bei der parallelen 2,4 GHz Nutzung durch die Haupt-Fernsteuerung (Taranis) und den WiFi-Transmitter für die Bildübertragung. Hast Du das mal über größere Entfernungen getestet?



#4 fingadar

fingadar
  • 532 Beiträge
  • OrtObernburg am Main
  • Hexakopter mit redundantem Pixhawk/Arducopter und RasPi3 Companion
    EZ-WifiBroadcast mit Auvidea HDMI-In
    FLIR Vue Pro R 640
    Lightware SF11 Lidar
    IR-Lock Precision Landing
    Emlid REACH RTK

Geschrieben 15. April 2017 - 07:36

Es gibt keine parallele 2,4Ghz-Nutzung mit der Haupt-Fernsteuerung. Die Taranis ist mit dem TBS Crossfire ausgestattet, das heisst, sie arbeitet im UHF-Band mit 868Mhz. Das funktioniert problemlos.

Parallel laufen, sofern an Bord, in 2,4Ghz die optionale Wifi-Strecke über die Ubiquities und die Videostrecke. Aber bei entsprechender Kanalwahl habe ich da noch keine Probleme festgestellt. Da stressen im urbanen Umfeld mehr die gefühlten eine Million Access Points von allen möglichen WLANs, die alle schreien: hier bin ich, nimm mich :-) da ist manchmal ein wenig Kanalsuche nötig, damit keine Bildstörungen auftreten. Das Wifibroadcast kann leider kein automatisches Frequenzhopping.
5GHz ist da leider keine Alternative, da digital nicht erlaubt. Nur analog.

Cooles Projekt!
Lidar steht auch noch auf meiner Wunschliste. Auch die Videoübertragung per Pi und WLAN ist interessant. Verwendest Du eine Pi Cam oder einen A/D Wandler?

Danke :)
Ich verwende wie gesagt ein Auvidea B101 als HDMI-Eingang für den PI. Es sitzt als Encoder an der Camera-Schnittstelle des PIs. Das B101 hat zwar ein paar Eigenarten, und unterstützt nicht alle HDMI-Modi, aber mit den von mir verwendeten Kameras geht es.
Ich habe von denen auch noch das B421 da, das soll mehr können und kompatibler sein. Aber ich bin noch nicht dazu gekommen, es zu testen.
Eine PI-Cam direkt ginge natürlich auch, das habe ich z.B. zusammen mit einem Pi0 als kompaktes Kamera-Wifi-Modul für meinen kleinen Flächenflieger gebaut:-)

Viele Grüße,
Stefan

Bearbeitet von fingadar, 15. April 2017 - 07:37.


#5 el Kopto

el Kopto
  • 1.689 Beiträge
  • OrtNorddeutschland
  • Hexa / Matrice 100 hybrid mod / Jordana Endurance mit N3 + LB2 + PulseKraft PWM Erweiterung

Geschrieben 15. April 2017 - 08:31

Es gibt keine parallele 2,4Ghz-Nutzung mit der Haupt-Fernsteuerung. Die Taranis ist mit dem TBS Crossfire ausgestattet, das heisst, sie arbeitet im UHF-Band mit 868Mhz. Das funktioniert problemlos.

...

5GHz ist da leider keine Alternative, da digital nicht erlaubt. Nur analog.

 

Bei dem 868 MHz Modul hätte ich gewisse Bedenken hinsichtlich der Zulässigkeit. Generell ist zwar die Nutzung des Bandes in Europa zugelassen, die Sendeleistung mit 25 mW mag auch noch in Ordnung gehen, aber es gibt weitere Restriktionen hinsichtlich des Duty-Cycles. Gibt es irgendwo entsprechende Compliance Erklärungen von TBS?

 

Wieso ist die digitale Videoübertragung im 5GHz Bereich nicht erlaubt? Connex macht es doch auch und wenn ich einen Videostream über mein 5 GHz Heim-WLan laufen lasse ist das doch auch nicht illegal?

 

Abgesehen davon ist jedoch die Reichweite der 5 GHz Lösungen eher dürftig, solange sie mit den erlaubten Sendeleistungen und Antennen operieren.



#6 fingadar

fingadar
  • 532 Beiträge
  • OrtObernburg am Main
  • Hexakopter mit redundantem Pixhawk/Arducopter und RasPi3 Companion
    EZ-WifiBroadcast mit Auvidea HDMI-In
    FLIR Vue Pro R 640
    Lightware SF11 Lidar
    IR-Lock Precision Landing
    Emlid REACH RTK

Geschrieben 15. April 2017 - 09:56

Da must Du keine Bedenken haben (bzw. ja eigentlich ich, denn ich fliege damit).

Das Crossfire war eines der Komponenten, das von Anfang an am wenigstens Aufmerksamkeit benötigt hatte. Ich fliege damit seit einem Jahr, und kann nur sagen, dass es nach wie vor seinem sehr guten Ruf gerecht wird. Ich hatte noch nie Probleme damit. UHF-Lösungen werden in Longrange-Bereichen immer verbreiteter. Der Reichweiten-Rekord in einem Test, allerdings da natürlich nicht mit legaler Sendeleistung liegt bei irgendwo 150km (gibt es ein youtube-Video dazu). Die CE-konforme Variante reicht allen seriösen Berichten zufolge gut in Mitte des einstelligen KM-Bereich hinein. Und was sollte das mit Duty Cycles zu tun haben? Die für eine Fernsteuerung benötigte Bandbreite ist mehr als gering (fast irrelevant, sonst würden die ganzen im 2,4er Band verbreiteten Verfahren so gar nicht funktionieren) und Duty Cycles sind ein Grundprinzip jeder digitalen Übertragung. Aber das kann Dir jemand mit mehr Fachwissen im Bereich drahtloser digitaler Verfahren erklären als ich :-)

Nebenbei hat das Crossfire noch den Nebennutzen, quasi gratis eine 57600-Baud-Srecke mitzuliefern und als Funkbake zu arbeiten. Der Diversity-Empfänger hat einen kleinen Lipo an Bord und "piept" damit. Eine Woche oder so hält der, und mit einem einfachen Aufsatz-Reflektor m Sender kann man den dann damit orten. Und beim Anschluss an Mavlink überträgt der Empfänger per Telemetriekanal die aktuellen GPS-Koordinaten an den Sender.

 

Und zu Deiner anderen Frage: die Bundesnetzagentur sagt das, siehe https://www.bundesne...icationFile&v=3

Das steht u.a. wörtlich: 6. Funkübertragungsstrecken zwischen WAS/WLAN-Funkstellen an Bord von Luftfahrzeugen und Funkstellen außerhalb von Luftfahrzeugen (z. B. am Boden) sind nicht gestattet.

 

Viele Grüße, 

Stefan



#7 el Kopto

el Kopto
  • 1.689 Beiträge
  • OrtNorddeutschland
  • Hexa / Matrice 100 hybrid mod / Jordana Endurance mit N3 + LB2 + PulseKraft PWM Erweiterung

Geschrieben 15. April 2017 - 10:44

Da must Du keine Bedenken haben (bzw. ja eigentlich ich, denn ich fliege damit).

 
Wenn Du öffentlich eine Lösung publizierst, die ggf. andere zu ähnlichen Bauten inspiriert, sollte das Thema durchaus (sachlich) diskutiert werden können.
 

Das Crossfire war eines der Komponenten, das von Anfang an am wenigstens Aufmerksamkeit benötigt hatte. Ich fliege damit seit einem Jahr, und kann nur sagen, dass es nach wie vor seinem sehr guten Ruf gerecht wird. Ich hatte noch nie Probleme damit. UHF-Lösungen werden in Longrange-Bereichen immer verbreiteter. Der Reichweiten-Rekord in einem Test, allerdings da natürlich nicht mit legaler Sendeleistung liegt bei irgendwo 150km (gibt es ein youtube-Video dazu). Die CE-konforme Variante reicht allen seriösen Berichten zufolge gut in Mitte des einstelligen KM-Bereich hinein. Und was sollte das mit Duty Cycles zu tun haben? Die für eine Fernsteuerung benötigte Bandbreite ist mehr als gering (fast irrelevant, sonst würden die ganzen im 2,4er Band verbreiteten Verfahren so gar nicht funktionieren) und Duty Cycles sind ein Grundprinzip jeder digitalen Übertragung. Aber das kann Dir jemand mit mehr Fachwissen im Bereich drahtloser digitaler Verfahren erklären als ich :-)

 
Es geht nicht darum, ob es gut funktioniert. Das glaube ich gerne, denn auch ich setze gerne Funkmodule (z.B. das RFM69HCW) im 868 MHz Bereich ein.
 
Der Duty-Cycle oder die "time on air" ist - vereinfacht gesagt - der Zeitanteil, den Du die Frequenz nutzt. Wenn keine Frequenzzugans- und Störungsminderungstechniken verwendet werden, darf der Duty-Cycle bei 25 mW in den meisten Bereichen des 868 MHz Bandes nur 1% betragen (pro Stunde also 36 Sekunden).
 
https://www.bundesne...icationFile&v=1
 
Was genau TBS da implementiert hat, konnte ich auf die Schnelle nicht finden. Auf der deutschen Seite (blaykeyeteam.de) schreiben sie jedenfalls dazu:
 
"Hinweis:
Die Verwendung und Betrieb dieses Produktes kann in Europa und anderen Ländern das Vorhandensein einer HAM Amateur-Funklizenz voraussetzen. In einigen Ländern kann der Betrieb sogar ganz verboten sein. Es obliegt Ihrer eigenen Verantwortung, vor der Inbetriebnahme, die jeweilige Gesetzeslage in Ihrem Land in Erfahrung zu bringen und entsprechende zu handeln."

 
 

Und zu Deiner anderen Frage: die Bundesnetzagentur sagt das, siehe https://www.bundesne...icationFile&v=3
Das steht u.a. wörtlich: 6. Funkübertragungsstrecken zwischen WAS/WLAN-Funkstellen an Bord von Luftfahrzeugen und Funkstellen außerhalb von Luftfahrzeugen (z. B. am Boden) sind nicht gestattet.

 
Das hieße dann also, dass Connex oder der 5,8 GHz Modus der neueren DJI Kopter bei uns nicht zulässig wären. Vielleicht liegt da aber auch nur ein Missverständnis vor, das andere Spezialisten aufklären können.



#8 339427

339427
  • 1.365 Beiträge

Geschrieben 15. April 2017 - 11:56

Ich habe mich etwas mit dem Thema beschäftigt und das ist gar nicht so einfach. Es gibt in dem Bereich unterschiedliche Normen und Einschränkungen welche zum Teil National ent- oder verschärft werden. 

 

Grundsätzlich gibt es EN 301 893 für den Bereich 5.15 - 5.35 / 5.47 - 5.725 GHz. In dem Bereich befinden sich WLAN und damit werden einfach digitale Daten übertragen. Solange obige EN eingehalten wird sehe ich keine Einschränkung bezüglich der Nutzdaten (sind ja eh Digital). 

 

Von 5.725 - 5.875 GHz gilt EN 300 440 und dort gibt es stärkere Einschränkungen bezüglich Leistung und Bandbreite darum dürfen dort z.b. FPV Analog Signale mit 25mW übertragen werden.

 

Im 433MHz / 868 MHz / 915MHz Bereich gibt es ziemlich starke Einschränkungen was Duty Cycles angeht (also On vs. Off Time des Sender auf einem bestimmten Kanal im genannten Bereich). Spannenderweise gibt es in der CH eine sehr nette Ausnahme etwas oberhalb von 433 MHz welche 500mW Sendeleistung mit einem DC von 20% erlaubt ansonsten gelten in den obigen Bereichen starke Einschränkungen von 1 - 10% DC bei 1-100mW da dies sehr stark von Garagenöffner, Funkschalter, Heimautomation etc genutzt wird und wenn dort einer mit 100% DC durch die Luft schwirrt geht das Garagentor nicht mehr auf. 

 

Die meisten obigen Bereiche schreiben überdies AFA / LBT (Automatic Frequency Adapataion und Listen before Transmit) sowie Nutzung ohne Garantie auf Störungsfreiheit und Nutzung unter der Bedingung, dass man niemanden Stört. Beklagt sich also jemand, kann das die entsprechenden Behörden mit dem Funkwagen auf den Plan rufen. 


  • el Kopto gefällt das

#9 fingadar

fingadar
  • 532 Beiträge
  • OrtObernburg am Main
  • Hexakopter mit redundantem Pixhawk/Arducopter und RasPi3 Companion
    EZ-WifiBroadcast mit Auvidea HDMI-In
    FLIR Vue Pro R 640
    Lightware SF11 Lidar
    IR-Lock Precision Landing
    Emlid REACH RTK

Geschrieben 15. April 2017 - 12:20

Für das Thema TBS Crossfire gibt es hier im Forum einen eigenen Threat http://www.kopterfor...ossfire/page-25 Es wäre sinmvoller, diese Diskussion dort weiterzuführen.

Viele Grüße,
Stefan

#10 Linuxbear

Linuxbear
  • 173 Beiträge
  • OrtLeipzig
  • NAZE32 F450 "Grizzly II", NAZE32 Rachel "Boar", Alpha 250 "Hornet", Alpha 110 "Moskito", Mini-Hexa "Purzel"

Geschrieben 15. April 2017 - 12:28

Wow, was für ein Projekt! Dafür zolle ich 100 % Respekt & Anerkennung. Es wäre toll, wenn du eine kleine Veröffentlichung der Komponenten mit Kaufpreis und event. Masse im Bereich "Tutorials" in Erwägung ziehen könntest. Weiterhin viel Erfolg.

 

Gruß -Linuxbear-



#11 fingadar

fingadar
  • 532 Beiträge
  • OrtObernburg am Main
  • Hexakopter mit redundantem Pixhawk/Arducopter und RasPi3 Companion
    EZ-WifiBroadcast mit Auvidea HDMI-In
    FLIR Vue Pro R 640
    Lightware SF11 Lidar
    IR-Lock Precision Landing
    Emlid REACH RTK

Geschrieben 15. April 2017 - 13:21

Wow, was für ein Projekt! Dafür zolle ich 100 % Respekt & Anerkennung. Es wäre toll, wenn du eine kleine Veröffentlichung der Komponenten mit Kaufpreis und event. Masse im Bereich "Tutorials" in Erwägung ziehen könntest. Weiterhin viel Erfolg.


Danke :)

Kann ich gerne machen. Vielleicht im Gegensatz zu manch anderen gebe ich mein Wissen gerne weiter, schliesslich steckt da auch eine ganze Menge davon drin, das auch nicht nur von mir kommt :-)
Was interessiert Dich denn besonders?

Viele Grüße,
Stefan
  • 339427 gefällt das

#12 Linuxbear

Linuxbear
  • 173 Beiträge
  • OrtLeipzig
  • NAZE32 F450 "Grizzly II", NAZE32 Rachel "Boar", Alpha 250 "Hornet", Alpha 110 "Moskito", Mini-Hexa "Purzel"

Geschrieben 15. April 2017 - 17:18

Das ist leicht gesagt: alles. Wer auch immer einen Hexa in der 5 Kg Klasse bauen möchte sollte sich daran orientieren können. Wird die eine oder andere Komponente nicht benötigt-weglassen; event. verbessern sich damit die reinen Flugleistungsparameter. Schon der jetzige Antrieb repräsentiert mehr als nur Mittelklasse. Ich erlaube mir mal zu behaupten: dieser Hexa setzt Maßstäbe. Ach ja, fast vergessen: urbi et orbi-frohe Ostern!

 

Gruß -Linuxbear-



#13 fingadar

fingadar
  • 532 Beiträge
  • OrtObernburg am Main
  • Hexakopter mit redundantem Pixhawk/Arducopter und RasPi3 Companion
    EZ-WifiBroadcast mit Auvidea HDMI-In
    FLIR Vue Pro R 640
    Lightware SF11 Lidar
    IR-Lock Precision Landing
    Emlid REACH RTK

Geschrieben 16. April 2017 - 13:23

Dann fange ich doch erst mal mit der "Einkaufsliste" des Hexakopters, gegliedert in die einzelnen Funktionsbereiche, an. 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 :) 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 :-)
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

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: http://www.globe-fli...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 :-)

 



#14 el Kopto

el Kopto
  • 1.689 Beiträge
  • OrtNorddeutschland
  • Hexa / Matrice 100 hybrid mod / Jordana Endurance mit N3 + LB2 + PulseKraft PWM Erweiterung

Geschrieben 17. April 2017 - 09:28

Danke für die detaillierte Aufstellung.

 

Du hattest ja nach ein paar Ansätzen zur Gewichtsersparnis gefragt. Ohne am Grundkonzept zu rütteln, wären das wohl nur punktuelle Optimierungen, also z.B.

  • leichtere Regler (40A Regler halte ich bei der Motorisierung für deutlich überdimensionert)
  • Höher integrierte Boards, also z.B. statt dem RasPi 3 + drei separaten UARTs ein kleineres, leichteres Board mit ähnlicher Leistung und bereits 3 integrierten UARTs, wie z.B. das NanoPi M2
  • Leichterer Frame (hattest Du ja selbst schon angedeutet)
  • Leichteres LiDAR, z.B. Leddartech LeddarOne (hat allerdings nicht die Reichweite des Ligthware LiDARs, für automatische Landungen sollte es aber ebenfalls genügen)
  • Leichteres Landegestell (das von Dir gewählte halte ich für Kopter, die unter 5 kg bleiben sollen, für überdimensioniert)

 

Wenn man auch am Grundkonzept rüttelt (DJI N3 + LB2), wäre sicher noch einiges an Gewicht einsparbar, allerdings müsste man dann z.B. für die Integration eines IR-Lock tiefer in die Onboard SDK Programmierung einsteigen.

 

Wie sind Deine Erfahrungen mit den Antigravity 4006 Motoren? Verschiedentlich wurde ja berichtet (z.B. im Ultra Endurance Thread), dass sie ein nicht gerade angenehmes Laufgeräusch (Pfeifen) haben.



#15 fingadar

fingadar
  • 532 Beiträge
  • OrtObernburg am Main
  • Hexakopter mit redundantem Pixhawk/Arducopter und RasPi3 Companion
    EZ-WifiBroadcast mit Auvidea HDMI-In
    FLIR Vue Pro R 640
    Lightware SF11 Lidar
    IR-Lock Precision Landing
    Emlid REACH RTK

Geschrieben 17. April 2017 - 12:39

Auch die Videoübertragung per Pi und WLAN ist interessant. Verwendest Du eine Pi Cam oder einen A/D Wandler?

 
Ich habe da noch etwas dazu ausgegraben :)
Einen Analogwandler (ein Logilink VR0001) hatte ich bei der FLIR-Box ja schonmal verbaut. Das funktioniert, allerdings darf man sich da auch keine Qualitäts- und Latenzwunder erhoffen. Aber zum Nicht-Racer-Fliegen reicht es. Auf dem Foto sitzt der oben links, Kabel und USB-Buchse gestrippt.
Angehängte Datei  IMG_3037_1500px.jpg   576,79K   3 Mal heruntergeladen

Mit nur einer Raspi-Kamera, einem Pi Zero und einem TP-Link TL722N habe ich mal das da gebaut, gedacht eigentlich für einen Flächenflieger:
Angehängte Datei  _MG_4732_1500px.jpg   224,67K   3 Mal heruntergeladen
Das kleine Teil wiegt 65g, geht mit 3-4S und hat einen UART nach draussen für die Telemetrie. Und damit es nicht nur flugwind-gekühlt funktioniert, hat es einen kleinen Lüfter bekommen, damit läuft es stabil stundenlang auch am Boden. Im Netz gibt es da auch einen Baubericht davon, die STLs findet man auf der EZ-Wifibroadcast-Github-Seite von Bortek.
 

Danke für die detaillierte Aufstellung.

Gerne, danke für die Vorschläge.
 
Die Hobbywing XRotor 40 sind tatsächlich größer, als sie sein müssten. Die XRotor kommen aber hervorragend mit den Niedrig-KV-Motoren zurecht, deshalb habe ich die ausgewählt. 30A würden auch reichen, aber die gibt es leider nicht (mehr).

Der RasPI3 ist deshalb meine Wahl, weil ich für die Videostrecke eine gut funktionierende und unterstützte GPU und CSI-Schnittstelle brauche. Bei fast allen anderen Boards, die ich mir angeschaut hatte, war das nicht gegeben (ausser vielleicht bei ODroid, aber da kann auch auch beim Pi bleiben). Entweder war die GPU-Unterstützung gar nicht vorhanden oder so mangelhaft, dass das eher Alibi war. Den NanoPi M2 kenne ich nicht genau, hat der vier UARTs? Andererseits macht das keine 10g aus, die CP2102 wiegen kaum was. Da würde es mehr ausmachen, die USB-Buchsen des PIs zu stripen, aber da war ich bislang zu faul (und feige) dazu.
Interessant würde das eventuell werden, wenn man den B101 durch einen B421 ersetzt, der encodiert Video in H264 in Hardware. Der E12 von Auvidea kann das zwar auch, aber der hat Probleme mit dem RTSP-Protokoll in Verbindung mit dem Pi (Ursache bisher unklar).

Das Landegestell ist bewußt ausgewählt, weil der Kopter eigentlich mal mit den T-Motor U5 für eine Gewichtsklasse bis zu 6-6,5kg vorgesehen war. Da wird jetzt die nächste Zeit zeigen, wie schwierig da aber die Verordnungslage werden wird, wir in Bayern waren da bislang ja sehr verwöhnt. Aber da hast Du recht, da gibt es Einsparpotential.
 

Wenn man auch am Grundkonzept rüttelt (DJI N3 + LB2), wäre sicher noch einiges an Gewicht einsparbar, allerdings müsste man dann z.B. für die Integration eines IR-Lock tiefer in die Onboard SDK Programmierung einsteigen.


In diese Diskussion möchte ich hier an dieser Stelle eigentlich nicht weiter einsteigen. Ich habe tatsächlich mit der LB2 geliebäugelt (früher auch mal mit dem A3). Aber aus unterschiedlichen Gründen (besonders die fast obligatorisch notwendige Verzahnung von LB2 und A3/N3) hat mich davon abgebracht.
Aber was ich toll und spannend fände, wenn Du mal in einem geeigneten Threat mal die Möglichkeiten bzw. Grundlagen der SDKs mal vorstellen würdest.
 

Wie sind Deine Erfahrungen mit den Antigravity 4006 Motoren? Verschiedentlich wurde ja berichtet (z.B. im Ultra Endurance Thread), dass sie ein nicht gerade angenehmes Laufgeräusch (Pfeifen) haben.


Eigentlich wäre mir da nichts wirklich aufgefallen. Hugo pfeift vielleicht ein bisschen deutlicher, seit der die 15" Carbon hat, früher (ganz am Anfang) mit 13" Aeronaut klang das, glaube ich, etwas anders. Aber das ist jetzt kein anderes Betriebsgeräusch als ich bei anderen Carbon-Prop-Koptern auch gehört hätte. Kann es vielleicht sein, dass die von Dir verwendeten ESCs eventuell Sync-Probleme mit den Motoren haben? Das würde das Geräusch erklären.
Ansonsten sind meine Erfahrungen mit den 4006 durchgehend positiv. Hervorragende Leistung bei nur 66g Gewicht.

Viele Grüße,
Stefan





Auch mit einem oder mehreren dieser Stichwörter versehen: eigenbau, multicopter, pixhawk, redundant, hexakopter

Besucher die dieses Thema lesen: 0

Mitglieder: 0, Gäste: 0, unsichtbare Mitglieder: 0