Naza flyaway?

Was trifft zu ?


  • Anzahl der Umfrageteilnehmer
    134
Status
Nicht offen für weitere Antworten.

FerdinandK

Erfahrener Benutzer
Failsave ist eine Eigenschaft des Empfängers, nicht vom Sender.

lg Ferdl
 
Man kann bei fast jedem Empfänger ein Failsafe programmieren das dann wenn der Funk abreißt geschaltet wird ...
Darauf muss jede FC reagieren . Wenn sie das nicht tut liegt irgend was im argen ...

Nach jedem Update der Firmware sollte man einen Hardware Reset durchführen und die Einstellungen händisch wieder herstellen und kein file einspielen da evtl. Das ein oder andere Bit nicht sauber gelöscht wird ...
 

Kholdstare

Erfahrener Benutzer
äh was soll ich darauf antworten..., vielleicht hab ich mich ja auch falsch ausgedrückt. Also der Empfänger arbeitet bis auf die Reichweite völlig normal. Sprich Failsafe Verhalten und zwangsläufig Programmierung....

Ich gebe dir Recht vielleicht vermag der Empfänger (weil defekt) nicht das "Richtige" Failsafe verhalten weitergeben. Was ich persönlich nicht glaube, ich habe eher das Gefühl das die Naza nicht immer das "richtige Failsafe" Signal interpretiert.... zumindestens sah das nach den Feldtesten so aus..

Demnach war es der Naza relativ wurscht ob nun Failsafe programiert (Schalterbelgung auf Failsafe) oder garnichts programiert. (Auswertung Fehlerbit, Futaba S-Bussignal)
Ebenfalls gleiches verhalten bei einem Jeti Empfänger, dort intressierte es die NAZA ebenfalls nicht ob nun Schalter für Failsafe programmiert oder nicht.

S-BUS protocol

The protocol is 25 Byte long and is send every 14ms (analog mode) or 7ms (highspeed mode).
One Byte = 1 startbit + 8 databit + 1 paritybit + 2 stopbit (8E2), baudrate = 100'000 bit/s
The highest bit is send first. The logic is inverted (Level High = 1)

[startbyte] [data1] [data2] .... [data22] [flags][endbyte]
startbyte = 11110000b (0xF0)
data 1-22 = [ch1, 11bit][ch2, 11bit] .... [ch16, 11bit] (ch# = 0 bis 2047)
channel 1 uses 8 bits from data1 and 3 bits from data2
channel 2 uses last 5 bits from data2 and 6 bits from data3
etc.
flags = bit7 = ch17 = digital channel (0x80)
bit6 = ch18 = digital channel (0x40)
bit5 = Frame lost, equivalent red LED on receiver (0x20)
bit4 = failsafe activated (0x10)

bit3 = n/a
bit2 = n/a
bit1 = n/a
bit0 = n/a

endbyte = 00000000b
Genau deswegen fliege ich klassisch mit PWM. 100'000 bps ungeschirmt über die diese labrigen Litzen, vorbei an Reglern und allem möglichem. Muss nur einmal bit4 auf high missinterpretiert werden und schon passiert das Uebel.
 

RCCopter

Coptertestingenieur
Also denke ich das so wie bei mir auch mit Graupner die einfache Failsafe Funktion zwar für ein Flächenmodell ok ist,aber z.B. Mit der Naza dahinter nicht reicht um jeder Kanal extra abgeschaltet werden muß damit die Naza selbst diese Funktion übernehmen kann.
Bei Graupner musst du den gewünschten (!) Failsafe im Empfänger abspeichern.
Graupner und Naza => Hier musst du einen Wert für U so abspeichern, dass U in der Naza auf Failsafe steht. Wenn nun die Verbindung vom Sender und Empfänger abreißt, schaltet der Empfänger den Kanal für U auf den vorher programmierten Wert. Für die Naza ist das dann Failsafe und wird dann ausgeführt. Dabei ist es völlig egal wie die anderen Kanäle stehen.

Genau deswegen fliege ich klassisch mit PWM.
Das halte ich auch so. Lieber ein paar Kabel mehr, die auch nicht viel wiegen.
 
Zuletzt bearbeitet:
@ Rolf.
Ich habe auch eine Mx16 Hott.Ist mir zum Glück auch noch nicht passiert! Aber warum beschreibt Graupner selbst diese Vorgehensweise in der Bedienungsanleitung? In der Kombi mit einer APM 2.5 hatte ich schon einmal das zweifelhafte "Vergnügen" eines nicht mehr steuerbaren Copter! Auf Nachfrage bei Graupner hat man das Problem Bestätigt und Abhilfe versprochen, bzw. Eine Warnung ausgesprochen das in einigen Fällen eine Fehlinterpretation des Graupner Failsafe Signal möglich ist!
 

FerdinandK

Erfahrener Benutzer
... ist auch meine Erfahrung, pro Kanal eine Ader. Manche Systeme lösen empfängerseitig leider nicht sauber failsave aus, da gibt es dann einen "fast kein Signal mehr" Zustand. Genau deswegen verwende ich das benannte System (Jeti) ja nicht mehr. Wenn der Empfänger bei Signalverlust nicht sauber jenen Zustand ausgibt der als failsave programmiert wurde kann die FC machen was sie will, sie weiß nicht, dass "failsave" von ihr verlangt wird.

lg Ferdl
 

Kholdstare

Erfahrener Benutzer
Ich programmier mein Failsafe so:

Kanal 1 - 4: Auf Mitte, keinesfalls auf hold
Kanal 5: Mitte (cam roll)
Kanal 6: auf full up (damit wenn crash's wenigstens die Linse der gopro nach oben schaut)
Kanal 7: auf failsafe, ist klar
Kanal 8: auf fpv cam (video switch)
Kanal 9: auf Out (Fahrwerk ausgefahren)
Kanal 10: auf On (Leds)
Kanal 11: auf On (LMF)
Kanal 12: auf Off (IOC)
 

Kienzle

Erfahrener Benutzer
... ist auch meine Erfahrung, pro Kanal eine Ader. Manche Systeme lösen empfängerseitig leider nicht sauber failsave aus, da gibt es dann einen "fast kein Signal mehr" Zustand. Genau deswegen verwende ich das benannte System (Jeti) ja nicht mehr. Wenn der Empfänger bei Signalverlust nicht sauber jenen Zustand ausgibt der als failsave programmiert wurde kann die FC machen was sie will, sie weiß nicht, dass "failsave" von ihr verlangt wird.

lg Ferdl
genau das ist der Punkt ein undefinierter Zustand, welcher nach meiner persönlichen Meinung auch das Problem für die Flyaways sind. Schaut man sich die meisten Video dokumentieren FA´s an. Sieht man häufig das der Kopter sehr wohl steuert und dann mehr oder weniger über eine Seite abkippt....
 

Kholdstare

Erfahrener Benutzer
Ein undefinierter Zustand muss nicht unbedingt ohne Signal heissen, solange ich das Protokoll und deren Fehlerkorrektur nicht kenne, lass ich die Finger davon. Man weiss ja nicht, ob die das Paritätsbit abfragen oder sowas wie ein CRC32 machen.
 

rolfsaegesser

Erfahrener Benutzer
@canoman
Auch ich habe schlechte Erfahrungen gemacht, wenn ich alles über eine Ader führen wollte (nicht in Kombination mit der Naza, das war damals glaublich ne Multiwii). Seither führe ich halt den ganzen Kabelsalat mit rum, sieht nicht schön aus, funzt jedoch zu 100%. Hatte seither nie mehr Probleme, inzwischen fliege ich ne Naza V1 und ne lite, bei beiden noch nie auch nur einen ungewollten Ruckler gehabt. Versuchs mal mit der Steuerung abstellen wenn Dein Copter irgendwo schwebt (natürlich, nachdem Du Dein Failsave richtig programmiert hast). Ist ein spezielles Gefühl, eine Fernsteuerung auszuschalten wenn das Modell noch in der Luft ist, hehe!
 

aargau

Erfahrener Benutzer
Moin moin,
ein Vereinskollege hatte gestern einen Absturz mit seinem Black Snapper, gut soweit kein Flyaway aber es macht mich doch ein wenig stutzig... Heraus gefunden haben wir das es ein defekter Jeti Empfänger ist. (Jeti DS14 mit einem R6 Empfänger, nicht konventionel verdrahtet)

Nun warum dann hier im Flyaway Thread:
Was wir feststellen konnten war das der Empfänger/ Sender einen Signalverlust hatte, die Naza jedoch nicht in Failsafe gegangen ist. Ein Sender ausschalten bzw. manuelles auslösen (Schalter) funktionierte auf der Werkbank, jedoch nicht im Flug.

Zum Absturz: DS 14 meldete Signalverlust, ein kontrolliertes Steuern war nicht mehr möglich, kontrolliert deswegen weil er kam zwar in unsere Richtung allerdings nicht kontrolliert und kippte dann über eine Achse ab, was darauf schliessen lässt das Teile des PPM Signals wohl ausgewertet wurden. Das Futaba S-Bus Protokoll sendet ja einen Bit welches die Naza dazu veranlasst in Failsafe zugehen. Bzw. alles anderen an Signale zuverwerfen und Failsafe auzulösen.

Ärgerlich bzw. erschreckend finde ich das die Naza wohl NICHT zuverlässig erkennt das ein Signalverlust vor liegt. (Die JETI Anlage hatte den an Futaba angepassten 20ms Impluls)
Genau das selbe Problem hatte ich beim Snapper auch, wenn ich meine FRSky X8R per SBUS Verbunden hatte. Mein Copter führte alles sauber aus, auch der Failsafe per Schalter klappte 1A. Ich wollte dann doch mal einen Livetest machen und schaltete die Funke einfach aus ;) Der Copter Flog etwas davon und drehte sich dann einfach um. Da ich auf 2-3m war blieb natürlich keine Zeit dies noch zu ändern...
Seit dem habe ich den Failsafe vom X8R geändert auf Sende zustand Mittelstellung auf allen Kanälen bis auf dem Modikanal, den habe ich so, dass er auf Failsafe geht. Nun klappt es ;)
 

Rheinperchten

Erfahrener Benutzer
Solange ein Empfänger ein eigenes Failsavesystem hat erkennt das die Nasa nicht als Fehler. Solange noch irgendwelche Signale im Fehlerfall vom Empfänger an die Naza gesendet werden kanns Probleme geben. Ausnahme ist, wenn der Empfänger im Fehlerfall die Naza Failsave gezielt auslöst/ansteuert. Aber wenn der Empfänger ne Vollmacke hat.......naja
 

kofferfisch

Erfahrener Benutzer
Gestern musste ich mit der Naza unangenhme Erfahrungen machen. Endlich gibts auch ein kurzes Video dazu.

Beim Testen des neuen Zenmuse Gimbals fing der Copter auf einmal an stark zur Seite zur driften und ließ sich nur noch durch starkes Gegensteuern (Maximalausschläge) auf der Stelle halten.

Beim Kontrollieren des Gopro-Clips fiel dann sofort auf, dass der Horizont in gleichem Maß verrückt spielt. Da beim Zenmuse Gimbal die Lageinformationen direkt aus der NAZA IMU in die Berechnung mit einfließen, habe ich den starken Verdacht, dass die Gyros oder Acc-Sensoren das Dilemma verursachen.
Die Naza wurde am selben Tag ausführlich kalibriert (IMU und Kompass).

Ab jetzt fliegt ein recht mulmiges Gefühl mit durch die Luft:(

Hier das Video von gestern (besonders interesant ab 1:00):
https://www.youtube.com/watch?v=ScdIElgIafA

Das ganze hat mich stark an dieses Ereignis erinnert:
https://www.youtube.com/watch?v=E8a4dp_NUdo

Was haltet ihr von der Geschichte?

Gruß

Kofferfisch
 

hopfen

Erfahrener Benutzer
*würg*...stimmt schon nachdenklich. Vor Allem deshalb weil ich vorgestern auch länger an der Naza mit der Advanced Kali am Tun war. Was mir bei der Cali gar nicht gefallen hat war die Tatsache, daß der Assi ständig monierte die Naza doch abzukühlen um ein besseres Ergebniss zu bekommen. Hab dann einen Beutel gefrorene Erbsen auf die Naza gelegt und gewartet bis sie runtergekühlt war..Wie gesagt, ich habe an diesem Tag die Advanced cali drei mal durchgeführt bis ich ein gutes Gefühl bei hatte alles richtig gemacht zu haben..Aber jedesmal war diese nicht nachvollziehbare Meldung dabei..Dazu kam, daß mir der Assi noch eine nicht nachvollziehbare Kompasstörung anzeigte. Also auch noch eine zusätzliche Fehlerquelle..
Ergebniss an diesem Tag. Das Gimbal hat jetzt einen tollen Horizont und passt..soweit..
Auffällig war:
Um bei der Caligeschichte eine kleine Wasserwaage auf die Naza legen zu können musste ich Spiegeltape lösen welches den Kompasstecker "fest fixiert". Dieser Stecker hat von Haus aus "viel" Spiel. Vom Gefühl her, zuviel Spiel! Dazu noch die ominöse Fehlermeldung eines Kompassproblemes bei der cali..
Stecker wurde wieder gegen lösen und seitliches arbeiten gesichert. Ergebniss: Gimbal arbeitet nun unauffällig gut.

@Kofferfisch: Mir ist in deinem Video aufgefallen, daß das Gimbal schon von Anfang an nicht sauber arbeitet. Es regelt auffällig lange nach wie der Kopter das erste Mal auf den Boden gestellt wird. Dann in der Luft sieht man schon auch sehr schnell das der Horizont schleppend nachgeregelt wird, bis es sich aufschwingt und zu dem Höllenszenario führt.

Da ich vor ca 2 Jahren mit der Naza starke Probleme hatte weil sie ständig, nachvollziehbar, in eine Richtung wollte und nur durch gegensteuern sich davon abhalten lies hab ich damals schon die Naza ein wenig respektvoller betrachtet. Hab dann mal vesuchsweise das GPS entfernt und Naza mit älterer FW geflasht. Naza lies sich nur noch durch hartes gegensteuern am Kippen verhindern..Bin nie hinter die Ursache beider Phänomene gestiegen, hab sie aber letztendlich durch mir bekannte Veränderungsmaßnahmen lösen können..
Irgendwie hängt da was zusammen ???

Wie geschrieben..der poppelige GPS Stecker muss bei mir gewissenhaft überprüft werden. Das muss bombenfest kontaktieren!
Nebenbei habe ich auch noch die Naza über den SBUS verbunden was mir kein gutes Gefühl mehr bereitet. Wenn es DJI schon als mögliche Fehlerquelle beschreibt..!
Fazit aus deiner Geschichte: Alle möglichen Fehlerquellen ausmerzen und die Naza mit noch mehr Aufmerksamkeit behandeln. In letzter Zeit hat man ja verstärkt Augenmerk auf aufkommende Schwingungen gelegt, Aber nur wegen des versauten Videobildes. Wer denkt denn schon grossartig daran das diese parasitären Schwingungen auch ständig an der empfindlichen Elektronik nagen.
Ich denke mittlerweile hat die Kopterelektronik einen Stand erreicht der zum Über- oder Umdenken zwingt.
Vielleicht überfordert mittlerweile die Technik sogar.. Wieso fällt mir dazu immer die Geschichte der jungen Bundeswehr und den Problemen an der F-104 von Lockheed ein..
DJI könnte sicherlich helfen das solche Horrorgeschichten weniger werden oder gar verschwinden, aber dazu müsste es von Gesetz in die Pflicht genommen werden :engel:
Mann Kofferfisch.. was machst du nur für Sachen.

Manni
 

kofferfisch

Erfahrener Benutzer
Tja, Manni, was mach ich nur für Sachen....

War gerade dabei, mit dem kleinen Zenmuse warm zu werden und dann so etwas. Im Prinzip ist´s bei mir fast identisch wie du dein Setup beschrieben hast (SBUS, Cali (manchmal mit Wärmeproblem)).
Für mich ich das Verhalten allerdings ein sehr deutlicher Hinweis Richtung Lagestabilisierung durch Sensoren und die auswertenden Algorithmen, weil die Fernsteuerung ja gar keinen Einfluss aufs Gimbal hat.

Welche Steckverbindung meinst du genau (Naza>PMU oder PMU>Pilz)? Ich bin in diesem Fall eher der Meinung, dass es hierbei nur verbunden oder unverbunden des Kontaktes geben müsste.

Klar, mit Vibrationen "kämpfe" ich auch, das letzte was mir nach ausführlichem Wuchten noch einfallt, wäre, die Lager an den Motoren zu tauschen (>echt aufwändig:()).

Zuletzt würden mich noch die von dir angesprochenen "bekannten Veränderungsmaßnahmen" interessieren.

Übrigens, deine Gimbal-Videos sind echt nett anzusehen;)
 

Kienzle

Erfahrener Benutzer
Moin,
mittlerweile habe ich auch eine Phantom2 und treibe mich bissel im kopterforum.de umher. Und das erschreckende ist, das dort fast täglich einer abhaut....!

@kofferfisch: Vor ca. 2 Jahren hatte ich das selbe Problem, äusserte sich genauso wie man es bei dir im Video gesehen hat, allerdings hatte ich es damals auf eine fehlerhafte FW geschoben (da häuften sich auch plötzlich die Probleme)

Nun kann man sagen es erhöht sich täglich die Anzahl der Kopterpiloten und somit auch evtl. Fehlerquellen. Aber irgendwie zerrt es doch an dem Vertrauen...
 
G

Gelöschtes Mitglied 1973

Gast
im kopterforum ist auch die geballte kompetenz unterwegs ;)
mal im ernst, ich stell hier ab und an mal n phantom ein, was da für fragen von leuten kommen die das ding schon fast nen jahr fliegen da kriegt man angst.

ich denke das 90% aller flyaways zwischen den ohren ablaufen ;)
 

kofferfisch

Erfahrener Benutzer
Apropos, zwischen den Ohren ablaufen... Hast du dir das Video mal angesehen? Du hast doch auch die gleiche Zenmuse und würdest das Gimbal-Verhalten wohl kaum als Anwendefehler abtun können.
Vielleicht könnte man die leidige Phantom-Diskussion außen vor lassen, ich fliege Copter seitdem es DJI gibt...
 
G

Gelöschtes Mitglied 1973

Gast
dein video hab ich damit garnicht gemeint! das hast du falsch verstanden.
bei dir passt definitiv was mit der imu/software was nicht, irgend ein wert läuft da aus dem ruder.
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten