Zum Inhalt wechseln


Foto

DJI N3 - Crasherkennung abschalten

dji naza naza-m multicopter

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

#1 liezenblau

liezenblau
  • 199 Beiträge
  • Hexacopter Thomasi 770 (redundanter Kopter für dicht besiedeltes Gebiet
    und
    Hexacopter Eigenbau für unbesiedeltes Gebiet

Geschrieben 18. September 2018 - 07:02

Kann mir jemand einen Tipp geben und sagen ob und wie ich beim DJI N3 Flugcontroller die Crasherkennung abschalten kann. Grund ist ein redundanter Kopter und es wäre höchst unangenehm wenn der FC Master auf Grund eines Fehlers vorschriftsgemäß in der Luft auf den FC Slave umschalten würde und dann aber der FC Slave aus irgendeinen Grund (z.b. längere Schräglage beim nach Hause fliegen - Coming home) schon auf Crasherkennung geschalten hätte.

 

Danke.

 

       



#2 WiSi-Testpilot

WiSi-Testpilot
  • 1.362 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 18. September 2018 - 07:45

Abschalten der Crasherkennung habe ich noch nirgendwo gelesen. Die N3 kann ja bis 45° Schräglage fliegen, also wird er bis zu diesem Winkel nicht die Motoren stoppen. Ich habe keinen Winkel gefunden, aber 70..80° müssten es schon sein, bevor die FC die Motoren abschaltet.
Viele Grüße,
Wilhelm


Bearbeitet von WiSi-Testpilot, 18. September 2018 - 07:47.


#3 fingadar

fingadar
  • 804 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 18. September 2018 - 08:14

@Wilhelm: Wie exakt die Crasherkennung funktioniert, hat DJI meines Wissens nicht dokumentiert. Von daher ist es schwierig zu sagen, ob das eine simple Winkelerkennung ist, oder ob noch andere Faktoren (wie beispielsweise noch eine Kombination von Winkel, Geschwindigkeit und Delta zwischen Soll/Ist-Attitude)mit einbezogen werden oder nicht. Gleiches gilt für die Landeerkennung. Die Algorithmen im Arducopter neigen defaultmäßig durchaus dazu, als "mitfliegendem" FC mal auf die Idee zu kommen, gecrasht zu sein. Das ist ja das Problem (meiner Erfahrung nach), einen modernen FC als Backup-FC mitfliegen zu lassen.
Ich persönlich spekuliere mal, dass das Problem in der Nach-Naza-Uralt-APM-Generation durchaus präsent ist, aber kaum untersucht bzw. berücksichtigt wird.

Deshalb ist es auch eigentlich unerlässlich, wenn die Umschaltelektronik vor dem Umschalten vorher prüft, ob der Backup-FC noch im Status Armed ist. Dazu müsste die Elektronik vor dem Umschalten den Status des Backup-Controllers aber erst auslesen. Das kenne ich dokumentiert nur von Mavlink-Systemen, ob das mit einer N3 geht, weiss ich nicht. Meine macht das, bzw. die liest die Telemetrie beider FCs kontinuierlich mit.

Eine Elektronik, die den Zustand des Backup-FCs vor der Umschaltung nicht prüft, ist eigentlich absolut fahrlässig. Und wenn z.B. die Austrocontrol so etwas als "ausreichend redundant" durchwinkt, ist das höchst bedenklich - oder albern, je nach Sicht der Dinge.

Viele Grüße,
Stefan

Bearbeitet von fingadar, 18. September 2018 - 08:21.

  • WiSi-Testpilot und Eye in the Sky gefällt das

#4 Eye in the Sky

Eye in the Sky
  • 257 Beiträge

Geschrieben 18. September 2018 - 10:10

PX4 kennt z.b. soweit ich weiss keinen Crash Detector lediglich einen Free Fall Detector, somit würde ein Umschalten wohl problemlos gehen. Allerdings können solche Umschaltvorgänge sehr unschön sein, wenn die Kontroller nicht völlig identisch kalibriert werden, da der Sollwert durch den Integrator völlig anders werden kann zwischen den beiden Kontrollern, und somit ein Umschalten zu einem ziemlichen "Step" führen kann. 

 

Grundsätzlich bin ich der Meinung, dass reine Controller Duplizierung mit einem weiteren Single Point of Failure (Decision Logik & Elektronik) eigentlich nichts bringt ausser Ärger. 

 

Wenn schon Redundanz, dann müsste das 3x sein mit eingebauter 2 out of 3 Voting Logik... Aber wer will das schon, abgesehen davon, dass es sowas bisher nicht gibt.



#5 fingadar

fingadar
  • 804 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 18. September 2018 - 14:33

Deshalb spriche ich üblicherweise von einer „Sicherheitsredundanz“. Volle Redundanz ist mit vernünftigem Aufwand nicht zu realisieren.

Mir hat meine Redundanz schon mal den Kopter gerettet, allerdings bastle ich auch ziemlich viel (und in dem Fall war der Fehler eher ein Stefan-selfmade-Problem:-) ). Ich wehre mich bei einem vernünftigen Aufbau aber, davon zu sprechen, dass ein neuer Single-Point-of-Failure dazukommt. Gut, bei der Verkabelung ja, sonst aber nicht.sonst taugt die Elektronik nicht.

Aber, egal wie man dazu steht, Redundanz wird von einigen offiziellen Stellen gefordert (und es ist abzusehen, dass im Zuge einer Sora-Beurteilung die Bedeutung noch zunehmen wird). Und diese Stellen richten sich eher weniger nach einer Privatmeinung :-)

Viele Grüße,
Stefan

#6 el Kopto

el Kopto
  • 3.462 Beiträge

Geschrieben 18. September 2018 - 22:54

Ich kann dem nur beipflichten. Die modernen "intelligenten" Flightcontroller - egal ob Pixhawk mit AC bzw. PX4 oder ein DJI A3/N3 - haben inzwischen so viele Dinge einprogrammiert bekommen, mit denen sie irgendwelche vermeintlich abnormen Zustände erkennen sollen, so dass schwer vorhersehbar ist, in welchem Zustand sich der Slave gerade befindet, wenn umgeschaltet wird. Auch beim N3 gäbe es natürlich Möglichkeiten, den Zustand vor der Umschaltung auszulesen (an der seriellen Schnittstelle mittels Onboard SDK), aber was nützt die Mühe dann noch, wenn der Master tatsächlich streikt? Das SDK ist recht gut dokumentiert, die Erkennungslogiken für Fehlzustände hingegen kaum. Bei Open Source FCs könnte man theoretisch noch in die Sourcen schauen, aber wer wird da schon alles durchflöhen, um sämtliche dieser Helferlein zu finden...

 

Den ganzen Stress damit würde ich mir nicht antun. Die Wahrscheinlichkeit, damit einen Kopter zu bauen, der unterm Strich weniger zuverlässig arbeitet, als einer ohne Umschalt-Platine, ist nicht gerade gering... Deshalb würde ich den Weg gehen, einen primitiven F3/F4/F7 Flightcontroller mit iNAV Flightstack als Slave zu nehmen. Bei dem ist zumindest halbwegs vorhersehbar, wann er wie reagiert. Um den Kopter am Stück wenigstens noch nach Hause zu fliegen, sollte auch iNAV taugen. Spart dann auch einiges an Gewicht und Geld.



#7 fingadar

fingadar
  • 804 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 19. September 2018 - 06:56

Hihi ... da gibt es einen Baubericht eines kleinen unschulidgen Hexas hier im Forum, der genau das Konzept „Primär Pixhawk - Sekundär Inav“ real und praktisch an Bord hat .. Sogar mit Link zu einem Video, das die Umschaltung zeigt :-)

Ein auf „dumm“ geschalteter Fx. mit Inav reicht völlig aus. Er soll den Kopter ja nur in der Luft halten und heil heimbringen.

Viele Grüße,
Stefan

PS: ja, ich weiss, ich hinke mit der autarken Umschaltplatine aud Basis einen Teensy hinterher; Asche auf mein Haupt, ich hatte die letzen Monate einfach zu wenig Zeit.

#8 liezenblau

liezenblau
  • 199 Beiträge
  • Hexacopter Thomasi 770 (redundanter Kopter für dicht besiedeltes Gebiet
    und
    Hexacopter Eigenbau für unbesiedeltes Gebiet

Geschrieben 19. September 2018 - 07:17

Vielen Dank für die Antworten und Hilfestellungen. Mir ging es einfach darum ob jemand weiß ob ich das ausschalten kann. Hab aber auch von DJI die Info bekommen, dass das nicht geht. Es gab aber bisher diesbezüglich keine Probleme, wollte nur zur Sicherheit die Dinge umstellen.

Auch ich habe lange überlegt, ob ich als Primärcontroller den N3 und als Slave den vorhandenen Wookong m verbauen soll. Die Wookong m ist aber doch schon relativ alt, nicht jetzt primär von der Technik her, sondern vom herumliegen und Produktionzeitpunkt. Auch da könnte ein Risiko auftreten.

Grundsätzlich stellt sich die Frage nicht, ob die Umschaltplatine sinnvoll ist oder nicht. Fakt ist, wenn ich im besiedelten Gebiet fliegen möchte ist diese gesetzlich notwendig. Fakt ist auch, dass die Auswahl dieser Umschaltplatinen, die Zugelassen werden nicht sehr groß ist.

Hab mich dann aber für die 2 N3 Controller entschieden. Aus folgenden Gründen:
1.) werden in Österreich von einem namhaften Hersteller in Kopter die 2 x N3 seit einiger Zeit verbaut und eingesetzt. Mittlerweile fliegen damit schon viele Kopter. Es gab bisher keine großen Probleme.
2.) Die Bauteile beim N3 sind neu

Das waren eben meine Überlegungen und hoffe ich habe da die richtigen Schritte gesetzt.

Aber danke für eure Tipps und Empfehlungen.

Bearbeitet von liezenblau, 19. September 2018 - 07:18.






Auch mit einem oder mehreren dieser Stichwörter versehen: dji, naza, naza-m, multicopter

Besucher die dieses Thema lesen: 0

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