Naza flyaway?

[seeers]

Ein Board ohne GPS kann sich genau gleich aufhängen und auch in eine Richtung davon fliegen, im zweifel wird so ein Copter aber schneller einschlagen da er die höhe nicht regelt.

Mein Beileid Bodo, hoffentlich liegt er nicht im Kanal....

Ich bin mir nicht sicher ob es Realistisch ist das der Copter dann weiterfliegt. Um den Copter in der Luft zu halten muss die FC weiterhin eine Lageregelung durchführen, ohne diese würde er sofort auf dem Boden liegen.
Ich selbst hatte auch mal einen selbstverschuldeten "Flyaway" mit einem Multiwii Copter. Ich war selbst schuld weil ich das WLAN der Gopro3 Cam angelassen habe und die Empfängerantenne direkt daneben saß.
Das Verhalten war ähnlich wie bei Bodo, er hat den letzten Steuerbefehl weiterhin ausgeführt und ist weg geflogen ohne ein weiteres Kommando anzunehmen.
Ich denke auch, dass die Ursache am Empfänger lag.

@Bodo weist du zufällig was der Empfänger im Failsafe Fall macht? Behält er den zuletzt Empfangenen Zustand?

 

[hopfen]

@FerinandK. da mag ich dir schon recht geben. So werden wir der Ursache nie auf die Schliche kommen.
Das hat der Thread Ersteller leider schon länger erkannt und das Thema in seinem Sinne als sinnlos "geschlossen". Tja, ich wäre schon alleine wegen der Tatsache das ich meine Nazas weiter verwende daran interessiert, wenn man mal ein Konzept reinbringen könnte um das Mysterium zu klären..Ferdinand, ich hatte vor Kurzem ein auffälliges Verhalten an meiner Naza mit abschließendem Absturz. Ich hatte das aufgezeichnete Video reingestellt mit chronologiscem sek Ablauf bis zum Einschlag..Wen hats interessiert..
Viele haben sich an dem Thema schon versucht..und sind gescheitert..Vielleicht haste ja recht und ich sollte einen Naza Jammer Thread eröffnen..Aber abschließend. Die Vogel Strauß Taktik hilft auch nicht weiter!

Manni

 

[FerdinandK]

@hopfen,

Es sagt keiner was von Vogel-Strauß, aber Hühnerstall wo alle sinnlos herumgackern bringt auch nix. Du hast selbst Dein Video richtig analysiert, was soll man da noch dazu schreiben?

lg Ferdl

 

[Der_Michel]

Hatte schon den Gedanken ob man Dji überhaupt rechtlich belangen könnte wenn durch so ein Fehlverhalten Schaden eintritt..
Manni

Da wirst Du wenig Freude haben, Seite 3 der GA ist ein sehr umfänglicher Haftungsausschluss, den Du mit der Nutzung der NAZA FC gelesen, verstanden und akzeptiert hast.

Gruss
Michael

 

[FerdinandK]

Also nochmal zum Thema FC (und deren SW). Bitte korrigiert mich wenn ich falsch liege, aber auf der FC ist ein Micro-Prozessor verbaut, das Micro bezieht sich auf dessen Fähigkeiten, es ist keinerlei Betriebssystem und schon gar keine Multitasking vorhanden. D.h. es läuft "das Programm" und dort befindet sich das Programm im "Main lopp", also in einer Kontrollschleife, wo Sensoren und Fernsteuerungssignale ausgelesen verarbeitet und die PWM-Werte für die Ausgabe an die Regler errechnet werden. Das passiert x-mal pro Sekunde. Steht diese Schleife (warum auch immer) purzelt der Kopter. D.h. da der Kopter (auf konstanter Höhe) davonfliegt läuft immer noch diese Schleifen, es werden weiterhin Sensordaten ausgelesen und die Ausgabe für die Motoren errechnent. Weil der Copter auf könstanter Höhe fliegt funktionieren immer noch Gyro (ohne Gyro direkt nach unten), ACC (ohne ACC keine maximale Neigung). Es bedeutet aber auch, das pro Schleife auch die Fernsteuerung ausgelesen wird, nur ist das Signal nicht brauchbar, oder es kommt kein Signal an. Ich meine man muss sich mit den Fragen.

Warum könnte das Signal der Fernsteuerung nicht brauchbar oder nicht vorhanden sein, oder von der Naza falsch interpretiert. Z.B es gibt ein (ppm-sbus) Signal, allerdings kommt nach dem decodieren nix vernünftiges heraus, daher keine Failsave und der alte Wert wird fortgeschrieben.

lg Ferdl

P.S.: Bei Flugmodellen war (und ist) es üblich, diese beim Erstflug als Totalausfall "abzuschreiben" und sich über jede "geschenkte" Stunde zu freuen. Wem das nicht genug ist, einfach einen Copter beim Spezialisten aufbauen, einfliegen und dessen Funktion garantieren lassen (wenn es denn so jemanden, so eine Firma gibt). Bis dahin würde ich weiterhin empfehlen, jeden Copter weiterhin beim Erstflug "abzuschreiben".

 

[Kaischu]

Ja genau oder wie bei mir, in Schräglage die Antenne vom Empfänger ab, d.h. Failsafe am Empfänger, da der aber auf Hold steht bleibt die letzte Eingabe stehen und er düst in der Höhe und der Neigung weiter bis lipo alle oder ein Berg im Weg ist!

 

[Blue Thunder]

Ja genau oder wie bei mir, in Schräglage die Antenne vom Empfänger ab, d.h. Failsafe am Empfänger, da der aber auf Hold steht bleibt die letzte Eingabe stehen und er düst in der Höhe und der Neigung weiter bis lipo alle oder ein Berg im Weg ist!

... oder es greift vorher die "receiver advanced protection function" sofern in der NAZA auch aktiviert.

Gruß BT

 

[seeers]

@Ferdl ich denke auch das es mit dem Empfänger zu tun hatte. Einen Bug in der Firmware ist doch sehr unwahrscheinlich. Mechanische Ursachen wie Stecker oder Antenne kommen da eher in Frage.

Ohne jetzt ein neues Fass aufmachen zu wollen, warum stellt eigentlich keiner die Empfänger und nur die FCs in Frage? Auf so gut wie allen Modernen Empfängern werkelt auch ein Mikrocontroller, der ausfallen oder einen Firmware Fehler haben KÖNNTE

Grüße Daniel

 

[hopfen]

@Der_Michel. War ja auch nur ein Gedanke ohne Wert.

Es ist halt so, daß man sich bei einer Fehlfunktion die zum Absturz führt erstmal richtig ohnmächtig vorkommt.. Da kommen dann Bilder hoch wie, abgebrannte Scheunen wegen miteingesammelten Lipo. Beschädigte Landmaschine..Oh Gott. Personenschaden..Wann geh ich zur Polizei und melde das Mißgeschick..oder doch nicht! Da fühlt man sich echt mies. Leider gehört zum Fliegen dazu das da mal ausfallen kann. Aber moderne FC in Verbindung von Videotechnik verleiten manchmal schon auch über Gebiete zu fliegn wo man sich im Schadensfall wünschte die Uhr zurückdrehn zu können.
Ich finde es gehört dazu. Nicht das Jammern, obwohl das schon befreiend sein kann, sondern sich die Tatsache der Verantwortung auch bewußt machen..Es muß nicht erst der allerschlimmste Fall eintreten bis wirklich was getan wird.

Die Frage wie wir mögliche Fehlerquellen erkennen, eingrenzen und dadurch beseitigen sollte wirklich ganz oben stehn. Es geht nicht darum die Transistoren und Widerstände in der Naza zu verstehn, sondern Auffälligkeiten im Flugbetrieb oder schon im Vorfeld zu erkennen..
Dazu: Wie nach meinem Absturz bekannt, habe ich die Verbindung der Naza zum X8R Empfänger wieder auf die klassische Art von S-Bus hergestellt. Gut, dachte ich mir. Im Assi alles schön neu eingestellt und überprüft. Weiter gut.. Als ich aber dann zuhause den Kopter entgegen dem üblichen Einschaltritual, Sender zuerst dann Empfänger bestromte blinkte die Naza betriebsbereit.. Also, ohne eingeschaltetem Sender betriebsbereit und nicht wie erwartet Failsafe!..Hab das dann mehrmals wiederholt und stellte meißtens das Gleiche fest. Noch schlimmer! Nachdem ich dann den Sender dazugeschaltet hatte und den FS bei Emfangsverlust testen wollte blinkte die Naza weiterhin im letzten Mode und ging nicht auf FS! Das ganze konnte ich mehrfach reproduzieren, aber nur wenn die Bindungsreihenfolge von der üblichen abwich..Mehrfach danach im normalen Bindemodus überprüft. Da schaltete die Naza nach abschalten des Snders schön in den FS durch.
Ehrlich gesagt, ist es mir auf dem Flugfeld schon passiert, daß ich zuerst den Kopter und danach den Sender zugeschaltet hatte. Kann fatale Folgen haben wenn man dann nicht durch das FS Blinken vor diesem Fehler gewarnt wird.

Nach dieser Ungereimtheit hab ich beschlossen die Naza wiede rüber den S-Bus mit dem Empfänger zu verbinden. Mehrfach die Bindprozedure bewußt unüblich vorgenommen und da ist dann die Naza auch bei Empfangsverlust wie erwartet in den FS gegangen. Auch wenn man den Empfänger ohne zuschalten des Senders bestromte. Was für die Sicherheit ja absolut wichtig ist..

Mir ist es halt beim überprüfen aufgefallen und ich kann nur Jedem raten wenn er die Naza, so wie ich, mit einem X8R betreibt es für sich mal zu testen. Also, zuerst Naza an, dann Sender.. Aber nur mit abgesicherter Antriebseinheit!..dann Sender aus und beobachten ob die Naza in den Failsafe geht. Mehrfach testen!

War jetzt wieder länger, gehört aber in Verbindung zu Naza Auffälligkeiten schon hier her..

Manni

 

[FerdinandK]

Ich denke eher, dass das "Auffälligkeiten" des Empfängers sind ...

 

[hopfen]

@FedinandK. wie ein Microcontoller arbeitet frage ich mich nicht. Ehrlich gesagt könnte ich das gar nicht verstehn weil die internen Abläufe einfach zu komplex sind. Ich kann das sagen, weil ich gelernter Kommunikationselektroniker bin. Is zwar schon eine Weile her wo wir mit dem Logik Analyator an einem 8085 mit 4,75 MHz..! gemessen hatten, aber wenn man das Ding Bit für Bit in Assembler programmiert hatte bekam man ein Gefühl für die Leistungsfähigkeit von CPU´s. Das war 1992.. Da hat sich viel getan und ich kann nur sagen. Es ist noch viel komplizierter als man meint..Das überlasse ich den Leuten die damit ihr Geld verdienen. Für mich sind die Kenndaten und Leistungsmerkmale der FC interessat. Die Anschlüsse. Damit kann und will ich arbeiten. Der Rest is ne Black Box auf die ich keinen Einfluss habe..Wie sagte mein ehemaliger Meß Guru. " Du sollst nicht die Transistoren in dem Gerät zählen, sondern plausible Meßergebnisse abliefern.."

Bin gespannt wie der richtige Ansatz aussieht. Werdens wohl wie die alten Fellhosenträger machen müssen. Beobachten und die richtigen Schlüsse daraus ziehen..

In diesem Sinne

Manni

 

[FerdinandK]

Jungens, Ihr macht das schon, viel Spaß dabei.

lg Ferdl

 

[schiwo1]

Mein Beileid, Bodo.
So wie du es geschildert hast duerfte er wohl ins Wasser gefallen sein.
Nach bisher ueber hundert Fluegen mit einer Naza V2 bei mir ohne besondere Vorkommnisse unter unterschiedlichsten Bedingungen glaube ich nicht an irgendeinen systematischen Fehler.
So wie jeder Computer oder Handy kann ein FC auch mal abstuerzen. 100% Sicherheit in komplexen Systemen gibt es nicht.
Wuenschenswert waere aber wenn die Naza ein Logfile protokollieren wuerde. Dann koennte man die "echten" Flyaways von all den Anwenderfehlern besser trennen
Gruss Stephan

 

[joe4copter]

Ich bin immer noch der Meinung das die Naza selbst bei richtiger Handhabung fast fehlerfrei ist bzw. Die Fehler sich im unteren Promillebereich bewegen. Aber als Inbetriebnehmer der tagtäglich mit komplexer und sensibler Hard/Software zu tun hat kann ich euch sagen es gibt kein fehlerfreies System !
Wobei die meisten Fehler eines Systems durch den Anwender verursacht werden ...

Dieser Tread hier ist mittlerweile eigentlich überholt und müsste neu aufgesetzt werden da fast keiner Fakten bringt !

@hopfen deine Analyse war richtig gut

 

[Bodo1963]

Hallo,
danke an alle für das Mitgefühl.

Werde jetzt erstmal mit dem alten Phantom weiter fliegen.

 

[Sunshadow8]

Dieser Tread hier ist mittlerweile eigentlich überholt und müsste neu aufgesetzt werden da fast keiner Fakten bringt !
@hopfen deine Analyse war richtig gut

Genau....wenn man das Ganze mal objektiv betrachtet, gibt es wahrscheinlich keinen Prozentsatz für "richtige" Flyaways sondern eher einen Promillesatz. Mal abgesehen davon.....nichts hält ewig. Ne Karre fängt an zu rosten, ne Alte fängt an zu nerven und die eigenen Gebeine fangen an zu klappern. So kriegt vielleicht auch ne Naza irgendwann Altzheimer und vergisst alles.....
Vielleicht ist es bzgl. Pilot und Flugkünste auch besser so....

 

[NilsG]

Hahahaha

Der beste Kommentar, diesen Thread zu schließen! Herrlich

Nils

 

[rchlx]

Nachdem ich mich gestern durch den Thread hier gekämpft habe, möchte ich nun auch noch meinen Senf dazu geben.

Da ich auch mit meinem Alexmos große Schwierigkeiten (I2C Fehler) habe ist für mich eigentlich eine Erklärungsvariante die naheliegendste: nämlich dass es hier um Fehler im Can-bus geht. Der Can-Bus lässt sich durch äußere Umstände beeinflussen, aber es ist eben nicht immer nachstellbar. Zumindest ist das so bei I2C und ich nehme an dass der Can-Bus vergleichbar ist.

Lösungsversuche wären hier:
-Ferritkerne oder eben Klappferrit, wie schon von einem anderen erwähnt. Das wiegt natürlich nicht wenig.

-Teilnehmer aus dem System entfernen. Zenmuse oder IOSD beispielsweiße. Bei Alexmos sind die Fehler nach hinzufügen einer zweiten IMU quasi explodiert

-Ein höherer GPS Mast

-Die Stromversorgung bereinigen: Spannungsfilter (siehe Blue Angel)

-die anderen Komponenten besser platzieren

- Ein Alu-Case für den FC. Eventuell macht es hier sogar Sinn das Case mit GND zu verbinden. Aber das wisst ihr vermutlich besser als ich.



Ich weiß auch dass ihr hier nicht über andere FCs reden möchtet, aber wäre der SuperX nicht die einfachste Lösung für die Problematik?

 

[gervais]

Z.T. Vernünftige Vorschläge. Wobei der des ZENMUSE Entfernens eher weder praktikabel noch sinnvoll ist. Dieses fantastische GIMBAL ist der einzige Grund, warum ich für meinen muß immer fliegen Copter immer noch die NAZA verwende.

Was die SuperX angeht...wieviele mag es davon geben ? Sobald die Masse die kauft, hat sich derlei Mythos auch erledigt.

Nur weil deren externer MAG (anscheinend) vor Fehlinstallationen/Funktion gefeit ist, bleiben Userfehler (Aufbau,Anwendung) und unerklärlicher Ausfall von Soft und (interner/externer) Hardware auch den Besitzern dieser FC nicht erspart.

 

[Blue Thunder]

Nachdem ich mich gestern durch den Thread hier gekämpft habe, möchte ich nun auch noch meinen Senf dazu geben.

Da ich auch mit meinem Alexmos große Schwierigkeiten (I2C Fehler) habe ist für mich eigentlich eine Erklärungsvariante die naheliegendste: nämlich dass es hier um Fehler im Can-bus geht. Der Can-Bus lässt sich durch äußere Umstände beeinflussen, aber es ist eben nicht immer nachstellbar. Zumindest ist das so bei I2C und ich nehme an dass der Can-Bus vergleichbar ist.

Lösungsversuche wären hier:
-Ferritkerne oder eben Klappferrit, wie schon von einem anderen erwähnt. Das wiegt natürlich nicht wenig.
-Teilnehmer aus dem System entfernen. Zenmuse oder IOSD beispielsweiße. Bei Alexmos sind die Fehler nach hinzufügen einer zweiten IMU quasi explodiert
-Ein höherer GPS Mast
-Die Stromversorgung bereinigen: Spannungsfilter (siehe Blue Angel)
-die anderen Komponenten besser platzieren
- Ein Alu-Case für den FC. Eventuell macht es hier sogar Sinn das Case mit GND zu verbinden. Aber das wisst ihr vermutlich besser als ich.

Ich weiß auch dass ihr hier nicht über andere FCs reden möchtet, aber wäre der SuperX nicht die einfachste Lösung für die Problematik?

Aus meinen Erfahrungen mit Wookong, Naza M V1, Naza Lite und jetzt Naza M V2 habe ich mir folgendes angewöhnt:

Aufbau des Kopters:

- alle HF Emittenten so weit wie möglich von einander und von der FC entfernt montieren (hierzu gehören insb. Kameras, Lipo-Warner, ESC und Video-TX)
- GPS-Pilz so hoch wie möglich montieren, auf Ausrichtung achten
- Video-Antenne möglichst unter dem Kopter anbringen
- Empfängerantenn(en) nicht mit Kabelbindern an den Auslegern befestigen, wenn an oder in diesen die ESC untergebracht sind
- Flugakku möglichst weit entfernt vom Kompass anbringen
- FC im oder dicht am COG sicher befestigen, auf Ausrichtung achten - wenn die FC sich im Flug löst, ist das nicht lustig
- immer Einzelkanalübergabe wählen (kein PPM oder S-Bus)
- bei der Verwendung von nicht 100%ig JR/Futaba kompatiblen RC-Systemen immer Einzelkanalübergabe wählen
- Servokabel, Empfängerkabel nicht zusammen mit stromführenden Kabeln bündeln
- Antriebe (Motoren und Propeller) gut auswuchten - Vibrationen können die Lagehaltung der FC stark beeinträchtigen
- auf ausreichenden Abstand zwischen drehenden Teilen (Propeller, Motor) und jeglichen Kabeln achten

Konfiguration von FC, Empfänger und Sender:

- Never change a running system! Wenn die FC läuft Finger weg von FW-Updates insb. wenn diese brandneu sind.
- IMU Kalibration nach dem Aufbau und danach bei Bedarf durchführen
- Kompass Kalibration vor dem Erstflug und dann nach jeder Änderung am Kopter erneut durchführen
- Schalter für den Flugmodus (GPS-Atti.-Man) muss (blind) gut erreichbar sein, ohne die Knüppel loslassen zu müssen
- Flugmodus "Manuell" nicht deaktivieren (wie häufig angeraten), sondern üben in diesem Modus den Kopter zu beherrschen (auch bei Wind!)
- "Failsafe" auf einen Schalter legen. Dieser muss gut erreichbar sein, aber darf nicht unbeabsichtigt betätigt werden können.
- "Receiver Advanced Protection Function" nicht aktivieren - statt dessen Empfänger-Failsafe mit Sinn und Verstand konfigurieren
- "IOC" nicht aktivieren (wer glaubt es zu brauchen, kann es aktivieren - muss es dann aber auch verstehen)
- "Flight Limits" horizontal großzügig (z.B. 1000m), vertikal auf max. erlaubte Flughöhe (z.B. 700m) einstellen.
- "Voltage Protection" abschalten - statt dessen Lipo-Warner, Telemetrie oder OSD verwenden
- Empfänger Failsafe für Kanal U konfigurieren und testen - auch an der Reichweitengrenze!
- Bei Einziehfahrwerk im Empfänger Failsafe "ausfahren" konfigurieren - sonst landet der Kopter ggf. auf dem Gimbal
- sich mit dem Verhalten der FC bei Failsafe genau vertraut machen, Vorgehensweise zur Wiederübernahme kennen und üben.
- GPS nur nutzen, wo es es Sinn macht - geradeaus fliegt der Kopter auch ohne und das sogar viel schneller

Vor dem Start:

- Propeller, Motoren, Steckverbinder und Akku auf sicheren Sitz kontrollieren
- Propeller von Insektenleichen befreien und auf Kollisionen mit anderen Bauteilen (z.B. Kabeln) prüfen
- W-Lan sofern auf dem Copter vorhanden abschalten!
- Lipo-Warner anschließen und Warnschwelle prüfen
- bei Klappkoptern Auslegerverriegelng prüfen
- Erst starten, wenn die FC komplett hochgefahren ist (bei GPS abwarten bis Home-Point gespeichert)

Damit bin ich bisher gut gefahren bzw. geflogen.

Gruß BT