Zum Inhalt wechseln


Foto

Projekt hochredundanter, BVLOS-tauglicher longrange HD Kopter

eigenbau modellbau multicopter redundanz hexa

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

#1 el Kopto

el Kopto
  • 3.069 Beiträge
  • OrtNorddeutschland
  • Hexa / Matrice 100 hybrid mod / Jordana Endurance mit N3 + LB2 + PulseKraft PWM Erweiterung, H920 Retrofit mit HyraCom BVLOS Steuersystem

Geschrieben 31. Dezember 2017 - 18:16

Bin gerade bei der Planung eines Kopters mit hoher Redundanz und hoher Reichweite der HD Funkübertragung sowie beyond-visual-line-of-sight (BVLOS) Tauglichkeit. Einige der "must-have"-Eckdaten:

  • Genügend redundanter Antrieb, also X8 oder Hexa. Vorzugsweise aber Hexa.
  • Doppelter Flightcontroller, doppeltes GPS/Kompass für hohe Ausfallsicherheit
  • (F)HD taugliche Bildübertragung mit >2km Reichweite

Optional "nice-to-have":

  • regenfest

Der Haupt-Flightcontroller soll in meinem Falle ein DJI N3 sein (prinzipiell wäre das Konzept aber natürlich auch übertragbar auf Pixhawk als Haupt-FC ;)), der Fallback-Controller hingegen benötigt nur einen geringen Funktionsumfang - er soll vor allem leicht und zumindest in der Lage sein, das Ding per GPS wieder an den Ausgangspunkt zurückfliegen zu lassen. Ich dachte dabei an einen F7 mit INAV, z.B. den von Stefan hier kürzlich erwähnten Mateksys F722.

 

Als HD-taugliche Funkübertragung mit der gewünschten Reichweite kommt derzeit eigentlich nur die DJI Lightbridge 2 in Frage, sie eröffnet dann auch viele der "intelligenteren" Features eines N3 und die Möglichkeit der Nutzung des Onboard SDK - zumindest solange man sich in deren Funkreichweite befindet. Das System soll aber auch BVLOS (beyond-visual-line-of-sight) tauglich sein. Aus meiner Sicht ist es nur eine Frage der Zeit, bis solche Systeme - natürlich unter heftigen Auflagen - genehmigungsfähig werden.

 

Da es jedoch ein ziemlicher Krampf ist, mit einer Lightbridge 2 aufgrund ihres proprietären Protokolls ein System mit zwei Flightcontrollern aufzubauen, dachte ich mir, dass es einfacher wäre, dem Backup-Flightcontroller eine eigene Funkübertragung zu spendieren. Dies erhöht auch nochmals die Ausfallsicherheit im Falle einer gestörten Haupt-Funkverbindung, sofern auch die manuelle Umschaltung über die Redundanz-Funkstrecke erfolgt.

 

Fallback auf 868 MHz Funkverbindung:

Denkbar wäre z.B. die TBS Crossfire oder das FrSky R9/R9M System. Zum Crossfire gibt es inzwischen auch einen nur rund 3g schweren Micro-Empfänger. Allerdings ist bei beiden Systemen bislang meine Skepsis hinsichtlich der Zulassung in DE nicht so ganz ausgeräumt. Die Sendeleistung lässt sich zwar bei den Systemen auf 10 mW begrenzen, für mich bleibt jedoch fraglich, ob sie auch den vorgeschriebenen Duty-Cycle einhalten. Eine Überlegung ist deshalb, die Funkstrecke für das Fallback-System selbst aufzubauen, z.B. mit zwei RFM95 Funk-Arduinos.

 

Fallback auf LTE (oder später 5G) Funkverbindung:

Die aus meiner Sicht interessantere Variante ist der Fallback bzw. die manuelle Umschaltung auf das LTE bzw. demnächst 5G Netz. Vorteil ist die nahezu beliebige Reichweite und die Möglichkeit, auch darüber das Bild zu übertragen, Nachteil die in schwach besiedelten Gebieten fehlende Abdeckung - BLVOS Flüge werden jedoch zunächst wohl gerade dort möglich sein.

 

Falls hier schon Erfahrungen mit den o.g. Fallback-Systemen vorliegen, wäre ich über Berichte und Tipps zu verfügbaren Lösungen dankbar. Von Stefan (fingadar) wissen wir, dass sein redundanter Hexa das TBS Crossfire nutzt.

 

Fallback-Flightcontroller:

Wie schon erwähnt, schwebt mir hierfür ein INAV Flightcontroller vor, z.B. auf F7 Basis. Leider habe ich damit bislang keinerlei Erfahrungen. Vielleicht hat jemand damit schon einen "großen" Kopter aufgebaut und entsprechende Erfahrungswerte, was die Einstellungen etc. angeht? Vorschläge für Komponenten?

 

Umschalt-Platine

Bleibt noch das Thema der Umschalt-Platinen. Der Klassiker ist hier sicherlich die "Koch"-Platine. Sie ist auch entsprechend bekannt bei der Austrocontrol, so dass Zulassungen damit sicherlich einfacher erreichbar sind, aber sie ist mit 460 EUR auch sehr teuer. Auch hier weiß ich, dass Stefan bei seinem redundanten Hexa eine eigene Platine gebaut hat. Soweit ich sein Konzept verstanden habe, basiert die Umschalt-Automatik auf einem zusätzlichen RasPi, der überwacht, ob der Telemetrie-Datenstrom am Pixhawk noch aktiv ist. Hier würde ich ggf. einen etwas anderen Ansatz wählen (grübele aber noch darüber...) - die Umschaltplatine an sich wäre aber schon eine sinnvolle Grundlage.
@Stefan: Vielleicht findest Du das Platinen-Routing noch...?

 

Akku-Redundanz

Einfache Parallel-Schaltung zweier LiPos reicht natürlich nicht aus. Es fehlt eine zusätzliche Schaltung, die einen Akku "abklemmt", sofern sein Spannung gegenüber dem anderen einbricht und sich ein Rück-Strom bildet. Ggf. lässt sich hier schon etwas mit entsprechenden Hochstrom-tauglichen Dioden bewerkstelligen. Ideen willkommen...

Webdex hat da natürlich auch was im Programm: https://www.webdex.a...hlusssicherung/ - auch das lassen sie sich aber gut bezahlen und es bringt einiges an zusätzlichem Gewicht.

 

So, nun heißt es erst mal, ins neue Jahr zu rutschen (bei hier aktuell 11°C)... :)


  • Ach-Mett und WiSi-Testpilot gefällt das

#2 vodoo

vodoo
  • 6.630 Beiträge
  • OrtSchweiz
  • DJI Phantom 1.2, H3-2D, Tiny OSD III
    Hammerhead Nano mit MT1306/2S
    UAV680 mit APM & Multistar 4822-490/4S, 14" Props
    RQR Infernale 2207-2100 / 6.5" Props

Geschrieben 31. Dezember 2017 - 21:04

Wie schon erwähnt, schwebt mir hierfür ein INAV Flightcontroller vor, z.B. auf F7 Basis.

 

Sei vorsichtig mit iNav auf F7 und wähle einen passenden FC. Die F7 Unterstützung ist noch ganz neu und erst für wenige Targets. Du findest sie hier:

https://github.com/i...eleases/tag/1.8

 

Frage: Wie ist 'long range' im vorstehenden Zusammenhang zu verstehen? Bis ca. 2 km?



#3 el Kopto

el Kopto
  • 3.069 Beiträge
  • OrtNorddeutschland
  • Hexa / Matrice 100 hybrid mod / Jordana Endurance mit N3 + LB2 + PulseKraft PWM Erweiterung, H920 Retrofit mit HyraCom BVLOS Steuersystem

Geschrieben 01. Januar 2018 - 11:02

Frohes Neues - und danke für den Hinweis. Ein paar F7 sind ja schon in der Liste. Bis das Projekt soweit ist, werden sicherlich noch ein paar dazukommen. Was micht interessiert sind Erfahrungen mit INAV auf größeren Koptern, z.B. brauchbare PID Werte (autotune brauchbar?).

 

"long range" meint sowohl eine große Reichweite der autarken Fernsteuerung und Bildübertragung z.B. für etwas großflächigere Suchaktionen als auch eine mehr oder weniger beliebig große Reichweite bei Nutzung von Funknetzen (UMTS, LTE, 5G). Autark sollte auch bei 2 km noch ein stabiles Bild geliefert werden. DJI gibt die LB 2 im CE Modus bis 3,5 km an. Bei 2 km hat man dann also noch etwas Reserve.


Bearbeitet von el Kopto, 01. Januar 2018 - 12:52.


#4 WiSi-Testpilot

WiSi-Testpilot
  • 1.114 Beiträge
  • Ortwestliches Münsterland
  • Kopter mit N3 & A3,
    Videoübertragung: LB2 mit CrystalSky & Connex.
    Kameras: Gopro H3+, Sony RX0,
    Sony A 6000 (NIR, Vis & UV),
    Flir Vue Pro R 640 (LWIR),
    Connex ProSight (NIR)

Geschrieben 01. Januar 2018 - 13:09

Frohes neues Jahr.

Dieser Thread wird bestimmt auch sehr interessant.

Mit ausreichend Budget würde ich den Reservepfad mit Connex Mini Long Range durchdenken. Mit dem Uplink über 5.8 GHz soll man eigentlich nicht den Kopter steuern, aber für den Notfall wäre das akzeptabel. Dann hättest du zwei unabhängige HD-Videostrecken und zwei Verbindungen für die Steuerung.

Edit:
Ein Plus dieses Konzeptes wäre noch, dass man den Reservepfad zB für die Gimbalsteuerung verwenden kann. Nur im Notfall oder zum Testen würde auf Koptersteuerung umgeschaltet. So schleppt man nicht immer das zusätzliche Equipment unnötigerweise mit.

 

Viele Grüße,
Wilhelm


Bearbeitet von WiSi-Testpilot, 01. Januar 2018 - 13:17.


#5 B69

B69
  • 2.984 Beiträge

Geschrieben 01. Januar 2018 - 13:17

Fallback auf 868 MHz Funkverbindung:

wow, anspruchsvoll - Respekt  :)



#6 el Kopto

el Kopto
  • 3.069 Beiträge
  • OrtNorddeutschland
  • Hexa / Matrice 100 hybrid mod / Jordana Endurance mit N3 + LB2 + PulseKraft PWM Erweiterung, H920 Retrofit mit HyraCom BVLOS Steuersystem

Geschrieben 01. Januar 2018 - 14:17

Nochmal zum F7 Flight Controller:

Soweit ich es bis jetzt sah,

  • fällt der Omnibus F7 (auch der neue V2) raus, da er nur 4 PWM / DShot Ausgänge hat. Eigentlich schade, denn das Konzept des V2 mit der in separater Masse gel-gelagerten IMU gefällt mir gut und onboard OSD kann ja nach Anwendungsfall auch sinnvoll sein
  • hätte der AnyFC F7 die meisten Ein- und Ausgänge, aber kein OSD onboard und nur eine MPU-6000 (wobei die 8K Samplingrate, die von dem Sensor unterstützt werden, für einen größeren Kopter sicherlich vollkommen ausreichen)
  • wäre der Mateksys F7 mit dem moderneren (32K tauglichen) Gyro, onboard OSD und auch schon mit einem Baro bestückt, wird aber noch nicht von INAV unterstützt (wohl nur eine Frage der Zeit).

@Wilhelm: Mit der Connex kann ich mich weiterhin nicht anfreunden. Auch die "long range" schafft die 3 km nur mit direktionaler Antenne, man muss also ausrichten. Ansonsten sind es nur 500m. Abgesehen davon finde ich sie zu teuer.

 

Für ein besonders leichtes Design überlege ich eher, die Funkübertragung für Steuerkommandos und Telemetrie nur auf 868 MHz (größere Reichweite!) oder 2,4 GHz Basis aufzusetzen und die Bildübertragung nur noch über LTE/5G laufen zu lassen. Das würde dann auch die Lightbridge und damit auch den N3 in Frage stellen. Die Lösung wäre damit erheblich günstiger zu realisieren. Ich erwarte auch immer noch in naher Zukunft eine weitere Alternative zur Lightbridge - vielleicht von denen: https://www.nxp.com/...RADIO-TELEMETRY

 

Die Redundanz-Lösung könnte dann ggf. auch aus zwei getrennten F7 bestehen, wenn man sich eh schon die Mühe macht, die Plattform mit einem F7 zum Laufen zu bringen.

 

wow, anspruchsvoll - Respekt  :)

 

Wieso anspruchsvoll? Oder übersehe ich da Ironie?



#7 B69

B69
  • 2.984 Beiträge

Geschrieben 01. Januar 2018 - 14:23

Oder übersehe ich da Ironie?

Nein, definitiv keine Ironie, ich finde das ein spannendes Projekt - hab übrigens die falsche Zeile zitiert, sollte "Fallback auf LTE (oder später 5G) Funkverbindung" sein



#8 fingadar

fingadar
  • 788 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 02. Januar 2018 - 11:38

Im Prinzip hat Deine Planung eine gewisse Ähnlichkeit mit meinem Hexa. Hier ist der sekundäre Flightcontroller ja auch nur als Backup gedacht, damit der Kopter heil nach Hause kommt landen kann.

 

Flight Control

Ich habe bei meinen ganzen Versuchen festgestellt, dass als Backup-FC alles, was mehr Features hat als die "Generation Naza", hier eher kontraproduktiv ist. Insbesondere solche Dinge wie Landing Detection, Crash Detection und andere moderne (eigentlich sinnvolle) Methoden moderner Flight Controller oder -stacks hier mehr stören als nutzen. Denn der Backup ist ja im "Normalflugbetrieb" von der direkten Einwirkung seiner Regelungen auf die Fluglage abgekoppelt. Arducopter z.B. kommt damit mit seinen ganzen "Highclass"-Features gar nicht gut klar, das EKF fängt sehr schnell an, sich zu beschweren und im schlimmsten Fall disarmed die Logik den Backup-FC auf Grund eines Crash Detects. Deshalb bin ich irgendwann auf den INAV umgestiegen, da dem im Horizont- oder Anglemodus solche Dinge völlig egal sind und er immer einfach brav regelt. Vorausgesetzt, man schaltet Dinge wie z.B. die Landeerkennung da auch ab :-) GPS am Backup wird bei mir erst im Moment des Umschaltens des FCs zugeschaltet, sprich, erst bei der Umschaltung wird der Flight Mode auf dem Backup auf PosHold umgestellt. Das verhindert unerwünschte Seiteneffekte.

 

FC-Umschaltung

Da ist keine große Magie dahinter. Meine kleine Schaltung funktioniert sehr problemlos, ist völlig simpel aufgebaut und robust. Wenn ich mal viel Zeit habe, route ich auch mal eine SMD-Version davon. Das Routing meines Prototypen habe ich natürlich noch, aber das ist ein diskret aufgebauter "Totschläger" :-) Die Umschaltung erfolgt entweder über einen RC-Kanal, oder durch "irgendwas". In meinem Fall hat der sowieso an Bord befindliche PI den "Nebenjob", auf die Existenz von Telemetriedaten zu achten und beim Ausbleiben dieser Daten vom primären FC, dann umzuschalten. Simple Trigger-Schleife in Python. Das Ganze mit einem kleinen Arduino zu machen, wäre genau so trivial. 

Von automatischen Umschaltungen auf der Basis von eigenen IMU-Daten, wie von manchen Anbietern behauptet, halte ich gar nichts. Denn auch wenn z.B. die Koch-Platine eine eigene IMU hat, konnte mir noch niemand plausibel erklären, wie diese IMU irreguläre Betriebszustände sicher erkennen will. Das fügt eigener solchen Schaltung nur wieder einen zusätzlichen Singe-Point-of-Failure dazu, der Nutzen ist aber faktisch kaum vorhanden. Damit eine sensorgesteuerte Erkennung wirklich (innerhalb gewisser Grenzen) funktioniert, bräuchte man eine gewichtete Plausibilitätsauswertung von mindestens drei unabhängigen Sensorkreisen. Und das sprengt den Umfang dann doch, denke ich.

 

Funk, Video und Telemetrie

Was die Backup-Funkstrecke angeht, kann ich bei DJI-Produkten nicht viel beisteuern. Das Mavlink-Ökosystem von PX4, Pixhawk und Co. hat den großen Vorteil, dass Mavlink halt von Vornherein auf solche Anwendungen ausgelegt ist. Ich kann über Mavlink prinzipiell ein UAV rein nur über die Telemetrie steuern. Das wird im Ausland bei BVLOS auch genutzt. Hier haben einige Gruppen praktisch bewiesen, dass es möglich ist, darüber UAVs über LTE im Bereich von >100km Entfernung zu steuern. Im Prinzip hat man so über die Telemetrie, wenn die eben nicht über die normale RC-Strecke (wie z.B. beim Crossfire) geroutet wird, automatisch eine Art von Redundanz. Mein Hexa z.B. hat dadurch quasi zwei unabhängige Mavlink-Kanäle: einmal über das Crossfire, einmal über Wifi. Die beiden "Kanäle" wirklich redundant zu verwenden, dazu wäre nur ein bisschen Logik und Routingprogrammierung an der Bodenstation nötig.

 

Wenn ich jetzt das Ganze wegen der Funkübertragung auf der Basis einer Lightbridge aufbauen würde, würde ich offen gesagt versuchen, die beiden Welten zu verbinden. Ich habe mich eh schon gewundert, dass noch nie jemand auf die Idee gekommen ist, mit ein bisschen teensy das Onboard-API eines DJIs mavlink-kompatibel zu machen :-)

 

Lipo-Redundanz

Die einzigen funktionierenden Systeme, die ich kenne, schalten "massig" parallel geschaltete, extrem verlustarme FETs. Also im Prinzip das, das Du schon auch gefunden hast. Ich denke, anders wird es auch nicht funktionieren. Auvidea hatte da zwar mal was mit einer Ideal-Dioden-Schaltung geplant, da ist aber glaube ich nicht etwas daraus geworden. Also auch hier: viele Mosfets, und das Ganze aber bitte dann gleich als PDB integriert. Sonst ist die Verbindung Lipo-Umschaltung <-> PDB ja wieder ein Single Point of Failure.

 

Regenfest ... Uff, ganz weiteres, komplexes Thema. Aber jetzt muss ich erst mal was arbeiten :-)

 

Viele Grüße und ein schönes Neues Jahr, 

Stefan

 


  • vodoo, Ach-Mett und WiSi-Testpilot gefällt das

#9 el Kopto

el Kopto
  • 3.069 Beiträge
  • OrtNorddeutschland
  • Hexa / Matrice 100 hybrid mod / Jordana Endurance mit N3 + LB2 + PulseKraft PWM Erweiterung, H920 Retrofit mit HyraCom BVLOS Steuersystem

Geschrieben 02. Januar 2018 - 13:06

Vielen Dank für Deine ausführlichen Kommentare, Stefan.

 

Je länger ich über die Sache nachdenke, desto mehr tendiere ich in die Richtung, dieses Mal gänzlich ohne DJI Komponenten aufzubauen :).

 

Habe mir bereits einen Matek F722 bestellt, inzwischen gibt es ja schon einen Release Candidate für ein darauf lauffähiges iNAV 1.8.1. Der Matek ist halt deswegen interessant, weil er bereits ein BMP280 Baro onboard hat und genügend PWM Ausgänge - auch für einen Hexa - hat. Lediglich vorm PID Tuning habe ich noch ein bisschen Muffen...

 

Ansonsten gibt iNAV eigentlich bereits alles her, was ich für die Plattform brauche. Als Telemetrie-Rückkanal werde ich den Smartport der FrSky Kombo Taranis X9D+ und X8R nutzen. Dann kann man schon mal ohne Bild-Übertragung testen. Die Taranis gibt zumindest nach deren Angaben 1,5km Reichweite her. Mit TBS Crossfire ginge dann auch mehr, auch wenn meine Bedenken hinsichtlich der Zulässigkeit in DE noch nicht gänzlich ausgeräumt sind. Die Übertragungsraten, die von TBS angebeben werden, können aus meiner Sicht eigentlich nicht mit einem 1/100 Duty-Cycle erreicht werden. Die Bedenken werden auch dadurch genährt, dass im Moment scheinbar kein Händler in DE die Crossfire liefern kann (oder will...).

 

Bis das ganze sauber fliegt, habe ich die leise Hoffnung, dass dann auch eine alternative HD Bild-Übertragung verfügbar sein wird. Wenn es dann sauber fliegt, die Waypoint-Funktionen meine Anforderungen erfüllen und eine brauchbare Telemetrie- und Bildübertragung umgesetzt ist, spricht eigentlich nichts dagegen, den F7 mit iNAV als Haupt-FC UND einen weiteren als Fallback zu verwenden.

 

Was dann allerdings noch zu klären wäre: Wie kommt iNAV bei einem Hexa mit dem Ausfall eines Antriebes klar? Gibt es da bereits Erfahrungen? Wenn er das nicht geregelt bekommt, wäre die zusätzliche Redundanz durch den Hexa-Antrieb wieder für die Katz... ???

 

Hinsichtlich Erkennung eines irregulären Betriebszustandes des Haupt-FC könnte man natürlich auch beim iNAV auf dessen Telemetrie-Daten zurückgreifen. Alternativ wäre vielleicht eine Überwachung der PWM-Ausgänge (zu den ESCs) denkbar. Wenn die Werte außerhalb realistischer Bereiche liegen oder sich über einen gewissen Zeitraum nicht ändern (FC hängt, aber die die PWM-Timer generieren immer noch den zuletzt eingestellten Wert), könnte dies aus meiner Sicht ein recht verlässlicher Indikator sein, dass eine Umschaltung erfolgen muss.


  • Ach-Mett und WiSi-Testpilot gefällt das

#10 fingadar

fingadar
  • 788 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 02. Januar 2018 - 15:24

Also was das PID-Tunen bei Inav angeht, da würde ich mir auch mal irgendwann einen Art funktionierenden Autotune-Mechanismus wünschen. Ich hatte die PIDs für meinen Hexa mehr oder weniger empirisch ermittelt. Also nicht unbedingt wissenschaftlich :-)

Die Lieferbarkeit vom Crossfire hat übrigens schlicht damit zu tun, dass TBS mal wieder nicht liefern kann Nicht nur in Deutschland, im Moment bekommst Du das in ganz Europa (wie es weltweit aussieht, weiss ich nicht) faktisch nirgendwo. Es dauert halt wieder, bis die nächste Charge produziert ist. Die Konformitätserklärung bekommst Du übrigens ganz problemlos von denen, und dass das Ganze eigentlich eine schweizer Entwicklung ist, ist ja wohl inzwischen allgemein bekannt.

Von der Überwachung der PWM-Ausgänge bin ich weggekommen, denn wie Du schon schreibst, ist das nicht unbedingt ein verlässlicher Indikator dafür, ob der eigentliche Flightcontroller noch sinnvolle Dinge tut. Abgesehen davon verbaust Du Dir damit als Konzept neue Ansteuerungsformen wie Oneshot o.ä. Nicht dass die derzeit schon wirklich essentiell wichtig wären, aber wenn man jetzt schon etwas neu konzipiert, sollte man das vielleicht im Hinterkopf haben.
Da eine Telemetrieüberwachung recht einfach zu realisieren ist, und der Fall, dass ein irgendwie abgestürzter oder ausgefallener FC weiterhin noch artig Telemetrie-Datenpakete sendet, ziemlich unwahrscheinlich ist, schien mir das der bessere Weg zu sein. Weniger Logik brauchst Du bei einer PWM-Überwachung auch nicht, denn die darf auch erst ab dem ersten Arming bzw. besser noch Abheben anspringen und muss sich beim Disarmen selbst deaktivieren. Also auch bei PWM-Überwachung brauchst Du etwas "mitdenkendes".
Abgesehen davon (mal für die Zukunft gesponnen) hat die Telemetrie-Überwachung auch noch den Vorteil, dass man damit eigentlich viel differenzierter (zumindest bei Arducopter oder PX4) die Betriebszustände des FCs beurteilen kann. Die Messages lassen sich ja leicht auswerten und verarbeiten.

In wie weit INAV mit Motorausfällen klar kommt, weiss ich leider nicht. Ich möchte als primären FC etwas Erprobtes, bei dem der Missionsflug elementarer Grundbestandteil der Konzeption ist, nicht missen. Bei INAV scheint mir der Missionsflug derzeit eher "Nebenprodukt" zu sein, im Sinne von: es geht schon mal ein bisschen. Deshalb: als primär-FC etwas "Großes", als Backup sehr gerne F3/F4/F7 mit INAV.

Für alternative Long-Range-Videosysteme kommt vielleicht mal das fpv.blue in Frage. Aber das ist noch in der Entwicklung und exisitert bislang nur in einer 1,2GHz-Version. Also nichts für den normalen Praxisgebrauch.
Wenn die Mobilfunk-Provider hier anders ticken würden, würde sich LTE anbieten. Damit wären eine ganze Menge Probleme auf einen Schlag ausgeräumt. Aber leider in den Betriebskosten derzeit unbezahlbar.

Viele Grüße,
Stefan
  • Ach-Mett gefällt das

#11 Ach-Mett

Ach-Mett
  • 10.816 Beiträge
  • OrtLübecker Bucht
  • WidowMaker 210
    AkKi 270 6S@1500KV
    Blade 380QX Ratte
    LaserQuad 480
    NightHawk X6 Beast
    Rolfi 3200KV 2S 4"
    710er SlowQuad 17"

Geschrieben 02. Januar 2018 - 16:19

Krasse Nummer - das klingt alles sehr interessant und ambitioniert - Hut ab, wenn das klappt.

 

Sollen die einzelnen TeilSysteme reundant sein oder soll beim Ausfall eines Teils ein kompletter FallBack von allem stattfinden?

Laufen ständig alle Systeme und wie entscheidet der Kopter, wann der jeweils redundante Teil genutzt werden soll?

 

Technisch kann ich mir z.B. auch schwer vorstellen, wie man einen BandHop von 2G4 auf 900MHz realisieren kann.

Funktioniert sowas einfach mit zwei Modulen in der Funke?

 

Besonders interessieren würde mich, wie die einzelnen Redundanzen funktionieren.

Ein mitfliegender RasPi überwacht die HauptFunktionen anhand von TelemetrieDaten und schaltet um?

Inklusive TelemetrieRedundanz mit dauerhaftem Vergleich beider DatenStröme?

 

 

Von mir gibts dafür schonmal den ersten FrickelAward 2018 :)

Wenn das steht, kannst Du zumindest in Österreich bestimmt gut damit handeln 8)

 

Thema gebucht...

 

 

 

 

PS:

Meine einzige Redundanz bleibt weiterhin suchen, aufheben und defekte Teile auf der WerkBank tauschen ;D ;)  :-[ 



#12 el Kopto

el Kopto
  • 3.069 Beiträge
  • OrtNorddeutschland
  • Hexa / Matrice 100 hybrid mod / Jordana Endurance mit N3 + LB2 + PulseKraft PWM Erweiterung, H920 Retrofit mit HyraCom BVLOS Steuersystem

Geschrieben 02. Januar 2018 - 20:34

Wenn die Mobilfunk-Provider hier anders ticken würden, würde sich LTE anbieten. Damit wären eine ganze Menge Probleme auf einen Schlag ausgeräumt. Aber leider in den Betriebskosten derzeit unbezahlbar.

 
Auch wenn die Tarife in DE im europäischen Vergleich eine ziemliche Frechheit sind (in Estland oder Litauen sieht das schon ganz anders aus ;) ), so lassen sich doch erträgliche Varianten finden.
 
Ich würde im Moment vermuten, dass man mit einem 2 Mbps Stream schon eine halbwegs brauchbare 720p Qualität hinbekommt. Das wäre in einer Stunde dann rund 900 MB Datenvolumen. Bei Vodafone zahlt man für 12 GB/Monat derzeit 27,49 EUR. Ist also noch überschaubar - eine Lightbridge 2 oder eine Connex gibt es ja auch nicht geschenkt...
 
Alternativ könnte auch ein Prepaid Internet-Stick von Congstar interessant sein. Bietet zwar nur HSDPA mit max. 7,2 Mbps, sollte aber auch genügen. Da gibt es dann eine "Tages-Flat" für 2,49 EUR.

 

Allerdings fallen die Kosten doppelt an...
 

Sollen die einzelnen TeilSysteme reundant sein oder soll beim Ausfall eines Teils ein kompletter FallBack von allem stattfinden?
Laufen ständig alle Systeme und wie entscheidet der Kopter, wann der jeweils redundante Teil genutzt werden soll?

 
Eher auf Basis von Teilsystemen. Einen Motor-/ESC-Ausfall sollte beim Hexa eigentlich schon der gerade aktive FC geregelt bekommen. Ob iNAV das kann, ist allerdings noch offen - Priorität hatte das in deren Projekt bislang sicher eher nicht...
 
Den Ausfall eines FC bzw. seiner Sensoren (GPS, Acc, Gyro, Magnetometer) sollte dann die FC-Umschaltung über die Umschalt-Platine ausmerzen können. Entweder, weil die Automatik es erkannte oder weil der Pilot manuell umschaltete.
 
Der Ausfall der primären Funkverbindung führt dann entweder zum RTH oder man kann sich noch mit der Umschaltung auf die sekundäre Funkverbindung (bei gleichzeitiger Umschaltung auf den sekundären FC) behelfen. Im Falle einer autonomen Mission wird diese auch bei Verlust der Funkverbindung zu Ende geflogen und automatisch gelandet.
 
Das Problem mit einem Akku regelt dann die Deaktivierung des defekten Akkus.
 

Technisch kann ich mir z.B. auch schwer vorstellen, wie man einen BandHop von 2G4 auf 900MHz realisieren kann.
Funktioniert sowas einfach mit zwei Modulen in der Funke?


Eine Umschaltung der Funkverbindung am Haupt-FC wäre in der Tat nicht trivial und diese Komponente könnte dann selbst wieder ein Single-Point-Of-Failure sein.
 
Wenn jedoch primärer FC und sekundärer FC jeweils eine eigene Funkverbindung haben, sollte die Umschaltung zumindest in einer Richtung simpel sein. Ob man dann noch wieder zurück zum primären FC kommt, hängt davon ab, in welchem Zustand er sich dann befindet. Das von Stefan umgesetzte Konzept erlaubte nur die Umschaltung vom Pix auf iNAV. Bei 2x iNAV klappt vielleicht auch die Rück-Umschaltung.
 

Meine einzige Redundanz bleibt weiterhin suchen, aufheben und defekte Teile auf der WerkBank tauschen ;D ;) :-[

 
Ja, bei Koptern klappt das i.d.R. noch ganz gut. Bei Personen, denen das Ding auf den Kopf fiel, weniger gut... ;)


  • Ach-Mett gefällt das

#13 sonic22

sonic22
  • 313 Beiträge
  • fraeskante.de Hexa
    quadframe V2 Hexa
    Chips & Grips
    T14SG
    Dragon II Gimbal
    Basecam ext. Encoder
    Zenmuse Z15
    Panasonic GH4
    Sony A7RII

Geschrieben 02. Januar 2018 - 21:33

 

Akku-Redundanz

Einfache Parallel-Schaltung zweier LiPos reicht natürlich nicht aus. Es fehlt eine zusätzliche Schaltung, die einen Akku "abklemmt", sofern sein Spannung gegenüber dem anderen einbricht und sich ein Rück-Strom bildet. Ggf. lässt sich hier schon etwas mit entsprechenden Hochstrom-tauglichen Dioden bewerkstelligen. Ideen willkommen...

Webdex hat da natürlich auch was im Programm: https://www.webdex.a...hlusssicherung/ - auch das lassen sie sich aber gut bezahlen und es bringt einiges an zusätzlichem Gewicht.

 

 

 

Hi,

bzgl. Akku-Redundanz könnte ich die Lipo-Decoupler empfehlen, 50A Dauer und 150A Spitze (15 sec.) sollten pro Lipo normalerweise reichen:

https://www.mikrocon...products_id=880

 

Diese würden auch gehen (hatte ich selbst verbaut):

https://www.der-schw...tikoper-a180362

allerdings ist hier eine Verlustspannung von rund 0,2V zu beachten, da sind die Lipo Decoupler besser

 

evtl. hilft das ja etwas weiter ;-}

lg


  • el Kopto gefällt das

#14 vodoo

vodoo
  • 6.630 Beiträge
  • OrtSchweiz
  • DJI Phantom 1.2, H3-2D, Tiny OSD III
    Hammerhead Nano mit MT1306/2S
    UAV680 mit APM & Multistar 4822-490/4S, 14" Props
    RQR Infernale 2207-2100 / 6.5" Props

Geschrieben 02. Januar 2018 - 21:51

Als Telemetrie-Rückkanal werde ich den Smartport der FrSky Kombo Taranis X9D+ und X8R nutzen.

 

Die X8R war das erste, was ich bei meinen Long-Range Versuchen rausgeschmissen habe. Dieser Empfänger hat schlicht keine Reichweite und zickt schon ab 1 km rum, wenn noch andere Funkwellen erzeugende Komponenten auf dem Kopter sind. Am Ende bin ich mit dem L9R glücklich geworden. Denn die eiserne Regel lautet, dass der RC-Kanal die beste Reichweite von allen Verbindungen haben muss. Habe mich zwar nie bis 14 km getraut, geht aber anscheinend:

 

 

Telemetrie hatte ich auf 918 MHz und zusätzlich die OSD Daten auf einem konventionellen 5.8 GHz Analog-Video Link. Ich bin übrigens sehr zufrieden mit den "lausigen" Analog Bildern, denn das Video bricht nicht einfach irgendwann ab, sondern hat zuerst einzelne Störungen, wird dann graduell schlechter, dann fällt die Farbe aus und wenn es zu Unterbrüchen kommt, dann kann man immer noch ca. 20% der bisherigen Strecke weiterfliegen und das Bild kommt je nach Position von Zeit zu Zeit wieder schwach rein. Das reicht dann, um kontrolliert den Rückweg anzutreten.

 

Der grosse Vorteil der LB2 ist, dass alles über einen einzigen Kanal läuft. Es hat mich viel Geduld, Nerven und alle Haare gekostet, bis ich kapiert habe, wie sich die verschiedenen Komponenten auf dem Kopter gegenseitig stören. Das ist das grösste Problem beim Long-Range.


  • el Kopto gefällt das

#15 el Kopto

el Kopto
  • 3.069 Beiträge
  • OrtNorddeutschland
  • Hexa / Matrice 100 hybrid mod / Jordana Endurance mit N3 + LB2 + PulseKraft PWM Erweiterung, H920 Retrofit mit HyraCom BVLOS Steuersystem

Geschrieben 03. Januar 2018 - 10:14

Mit ausreichend Budget würde ich den Reservepfad mit Connex Mini Long Range durchdenken. Mit dem Uplink über 5.8 GHz soll man eigentlich nicht den Kopter steuern, aber für den Notfall wäre das akzeptabel. Dann hättest du zwei unabhängige HD-Videostrecken und zwei Verbindungen für die Steuerung.

 
Ich würde gerne noch mal kurz auf das 5 GHz Thema zwecks digitaler Bildübertragung zurückkommen (5,8 GHz ist ohnehin nur für analoge Übertragung vorgesehen). Schaut man sich die Verfügung der Bundesnetzagentur an...
https://www.bundesne...icationFile&v=3
 
...dann ist nur der Frequenzbereich 5470 - 5725 für die Nutzung außerhalb geschlossener Räume zulässig. Auch hier gilt dann noch folgende Einschränkung:

"6. Funkübertragungsstrecken zwischen WAS/WLAN-Funkstellen an Bord von Luftfahrzeugen und Funkstellen außerhalb von Luftfahrzeugen (z. B. am Boden) sind nicht gestattet."

 

Ich frage mich deshalb, ob damit z.B. eine Connex, die in dem Bereich arbeitet, überhaupt in DE zulässig ist. Wenn ja, dann wäre dies hier vielleicht die interssantere Alternative: https://www.foxtechf...deo-system.html

Zumindest dann, wenn auch der Bereich 5470 - 5725 einstellbar ist (in deren Demo-Video nutzen sie 5180 MHz, was in DE nur innerhalb geschlossener Umgebungen erlaubt wäre).







Auch mit einem oder mehreren dieser Stichwörter versehen: eigenbau, modellbau, multicopter, redundanz, hexa

Besucher die dieses Thema lesen: 1

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