apm 2.6 absturz

lans38

Erfahrener Benutzer
#1
Hallo,

am WE hatte ich 2 Abstürze mit meinem neu aufgebauten BlackSnapper. Den ersten Absturz hatte ich quasi beim Jungfernflug. Ich war erst angenehm überrascht wie gut der Kopter mit den Standardwerten in der Luft steht; hab dann aber trotzdem das Autotune gestartet. Tja 5 bis 10 sekunden später dann die Ernüchterung....bei einer Rollbewegung stürzte der Kopter ab. Das hab ich jetzt eigentlich nur von megapirate gehört. Glücklicherweise war nur der Propeller vorne links hinüber.
Vom autotune wollt ich erst mal die Finger lassen und hab aber um die vibrationen zu messen logging erweitert auf default+imu.
Wieder draussen auf dem Feld gings erst hin und her hoch und runter, alles ohne Probleme. Dann gas + roll links und kopter kippt plötzlich zur Seite und stürtzt unkontrolliert in den Acker. Wieder Glück gehabt nur wieder der Propeller vorne links ist hin. Allerdings hatte ich nun keine Props zum wechseln mehr:(

Mein Setting:
Rahmen Black snapper
APM 2.6 von GLB
ESC: RCTimer Opto 30A ESC mit SimonK FW
Motoren: T-Motor MT2216 800KV v2
11" Graupner Props

Ich bin bisher nur Megapirate 3.x geflogen und hätte solche Spontanausfälle eher dort vermutet. zumindest hat man das dort gelesen und irgendwie damit gerechnet, wobei bei mir nie was passiert ist.

Leider kann ich mit den Logs nicht so viel anfangen. Vielleicht kann mir einer hier etwas unterstützend unter die Arme greifen??
Die Motoren sind erpropt der APM und die Regler sind neu.
 

Anhänge

Zuletzt bearbeitet:

seeers

Erfahrener Benutzer
#2
Hi Lans,

hier wurde vor kurzem ein alter Bug gefunden: http://diydrones.com/forum/topics/l...g-bug?id=705844:Topic:1608356&page=1#comments

Anscheinend kann es zu abstürzen kommen wenn viel Roll und Pitch gegeben wird:
There are three factors that must come together to cause this bug to be seen.
1. High throttle command
2. High roll output to motors
3. High pitch output to motors
and it helps if yaw is high too.

Evtl. kommen diese Zustände auch während des Autotunes zustande(nur eine Vermutung)

Der Bug ist jedenfalls mit der nächsten Firmware gefixt:
+ArduCopter 3.1.3 7-Apr-2014
+Changes from 3.1.2
+1) Stability patch fix which could cause motors to go to min at full throttle and with large roll/pitch inputs
+------------------------------------------------------------------

Grüße
Daniel
 

lans38

Erfahrener Benutzer
#3
Oh danke fuer den Tipp. Einen Versuch ist es auf jeden Fall wert. Muss aber erstmal nen bootloader auf den APM clone draufgekommen um die Firmware zu aktualisieren. Naja bis dahin hab ich wohl auch wieder props:)
 

KA8

Erfahrener Benutzer
#4
was stellt Ihr mit den Boarts an Bootloder flashen?? nach 20 Stck APM die installiert worden sind solche Probleme nie aufgetreten.
Dann wundert ihr euch das die Teile abschmieren.
Solche Abstürze lassen wir mal den Bootloader aussen vor lassen auf Vibration, und weichen Frame schließen, wenn dann alles nicht richtig abgeschirmt ist gibt der Mag_compass den Rest.
 

lans38

Erfahrener Benutzer
#5
Also erstmal war gar kein Kompass mit dabei. Und dann ist der black snapper frame alles andere als weich.
Auf dem apm clone von glb ist wohl kein bootloader installiert, daher kann man die Firmware nicht ohne weiteres updaten. Hab noch keine Zeit gefunden dies nachzuholen, hoffe aber am we das tun zu können.
 
#6
Hallo lans88,
die Vibrationen sind im Bereich den 3DR als ok bezeichnet, würde ich mal sagen.
Das kleinere Logfile hat noch keine IMU-Werte. Gehe davon aus, dass es der erste "Absturz" war mit Crash detect.
Hier sieht man, dass kurz vor dem Absturz ein I2Cerr erscheint (0>1), der im zweiten Logfile
auf dem Wert 1 bleibt.

Hast du etwas am I2C-Port angeschlossen?
Powerboard?
 

KA8

Erfahrener Benutzer
#7
Der Compass oder Mag genannt ist auf der APM ein HMC 5883L der ist auf deinem Board installiert,! und immer dabei es sei denn du hast den Sensor in deinen GPS mit eingebaut oder ein externen.

viel Erfolg
 
#9
@KA8
...ein APM 2.6 hat keinen Compass auf der Platine. Ein externer wird über den I2C-Port angeschlossen. Die Vorversion 2.5.x hatte noch einen internen, den man aber auch "abschalten" konnte (meine eine Lötbrücke)...

Um eine GLB-Board zu flashen nimmt man am besten Arduino. Dort sind alle möglichen Bootloader für die Boardversionen integriert. Geht flott und unproblematisch....
 
Zuletzt bearbeitet:

hulk

PrinceCharming
#10
Die boards mit dem bootloaderproblem waten meist woanders her. Glb hat manchmal vertauschte Kabel oder kompass spinnt.....aber nicht flashbar ist höchst selten!
 
#11
dann war ich auch einer dieser seltenen Fälle :D

Aber hast recht...besonders der Fred "APM für 45€" ist da wohl der HIT gewesen....!!!!
Manchmal ist günstig eben teuer!
 

brm

Erfahrener Benutzer
#12
Hi Lans,

hier wurde vor kurzem ein alter Bug gefunden: http://diydrones.com/forum/topics/l...g-bug?id=705844:Topic:1608356&page=1#comments

Anscheinend kann es zu abstürzen kommen wenn viel Roll und Pitch gegeben wird:
There are three factors that must come together to cause this bug to be seen.
1. High throttle command
2. High roll output to motors
3. High pitch output to motors
and it helps if yaw is high too.

Evtl. kommen diese Zustände auch während des Autotunes zustande(nur eine Vermutung)

Der Bug ist jedenfalls mit der nächsten Firmware gefixt:
+ArduCopter 3.1.3 7-Apr-2014
+Changes from 3.1.2
+1) Stability patch fix which could cause motors to go to min at full throttle and with large roll/pitch inputs
+------------------------------------------------------------------

Grüße
Daniel
märchen - ich bin weit über ein jahr nicht mehr apm geflogen.
wegen den blöden sw bugs ...
mit roll gaaanz links und roll gaaanz rechts hast du einen guten test.
ganz schnell ausgeführt führt das zu viel dynamik.
mit beschissenen filtern erzeugst du so viel phasenverschiebung, dass der copter
aus der luft fallt.
auch ein grund warum bei 3dr nur grosse kopter zu haben sind ...

filter höherer ordnung reagieren auf schnelle änderungen mit überschwingen.
ein weitere technischer ko für kopter ...

ist aber interessant zu hören ;-)

robert
 

brm

Erfahrener Benutzer
#14
Da ist übrigens noch der googlecode text dazu: https://groups.google.com/forum/#!topic/drones-discuss/vesQUdWYOiQ
Ich dachte immer, da wäre so eine TestSoftwaresuite, die vor dem Upload schon den Code auf Herz und Nieren durchtestet? Eigentlich eine super Sache, nur funktionieren muss sie...
nö - man will verkaufen.
die banane reift beim kunden.
wenn du bei mahony und co zu viel wegfilterst mit einem low pass filter, dann passiert dies:
https://www.youtube.com/watch?v=ZfR7XOPUxhU
sobald die änderungen da sind kommt die sensor fusion nicht mehr mit.
 

KA8

Erfahrener Benutzer
#15
hier wird etwas völlig aus den Zusammenhang bezüglich des Bug erzählt, dieser ist schon seit Version 2.9 vorhanden, und fast nie aufgefallen, erst wenn ihr Wegpunkte fliegt die unter der Höhe der eingestellten RTL höhe ist, und dann per Schalte RTL aktiviert wird, und der Copter steigt, kann es vielleicht, zu einem Absturz kommen.
Postet doch mal die Logs, dann ist das einwandfrei zu erkennen.
Frage an Robert welcher Bug soll das sein? welche Phasen willst du verschoben haben. auch nett das Video, nur bitte wo sind die Logs die diese Vermutungen belegen ?
Ganz so einfach wie hier die überaus komplexe Regelung der Fluglagen im Zusammenhang und Abhängigkeiten der Sensoren, und
der Filter beschrieben werden ist es leider nicht, und gerade weil dieses nicht immer Verstanden wird, und bei der Abstimmung der Copter sehr oft an Parametern Veränderungen vorgenommen werden, die nicht bedacht wurden, was daraus resultiert,
und Halbwissen übernommen wird, wird ein riesiges Spinnennetz um eine Sache gesponnen, die eigentlich nicht vorhanden ist.
Es gibt ein riesengroßes Wiki von 3dr, dieses kann ich jedem Empfehlen.
Auch nach sehr sehr vielen verbauten APMs im hohen 2stelligen Bereich habe ich solche Probleme von denen ich hier lese leider nicht gehabt,
da habe ich wohl etwas fasch gemacht .
 

brm

Erfahrener Benutzer
#16
hier wird etwas völlig aus den Zusammenhang bezüglich des Bug erzählt, dieser ist schon seit Version 2.9 vorhanden, und fast nie aufgefallen, erst wenn ihr Wegpunkte fliegt die unter der Höhe der eingestellten RTL höhe ist, und dann per Schalte RTL aktiviert wird, und der Copter steigt, kann es vielleicht, zu einem Absturz kommen.
Postet doch mal die Logs, dann ist das einwandfrei zu erkennen.
Frage an Robert welcher Bug soll das sein? welche Phasen willst du verschoben haben. auch nett das Video, nur bitte wo sind die Logs die diese Vermutungen belegen ?
Ganz so einfach wie hier die überaus komplexe Regelung der Fluglagen im Zusammenhang und Abhängigkeiten der Sensoren, und
der Filter beschrieben werden ist es leider nicht, und gerade weil dieses nicht immer Verstanden wird, und bei der Abstimmung der Copter sehr oft an Parametern Veränderungen vorgenommen werden, die nicht bedacht wurden, was daraus resultiert,
und Halbwissen übernommen wird, wird ein riesiges Spinnennetz um eine Sache gesponnen, die eigentlich nicht vorhanden ist.
Es gibt ein riesengroßes Wiki von 3dr, dieses kann ich jedem Empfehlen.
Auch nach sehr sehr vielen verbauten APMs im hohen 2stelligen Bereich habe ich solche Probleme von denen ich hier lese leider nicht gehabt,
da habe ich wohl etwas fasch gemacht .
schüttle die apm platine mal richtig und schaue wie sich der künstliche horizont bewegt ...
zähle die Sekunden ...

es gibt einen grund warum der ekf von paul riseborough einzug hält.
es verstauben drei apm's ...
 

lans38

Erfahrener Benutzer
#17
So es war wieder Wochenende und Zeit für einen erneuten Flug(Versuch). In der Zwischenzeit hatte ich kleinere Änderungen vorgenommen.
- Firmware von 3.1.2 auf 3.1.1 runter (ging dann doch problemlos mit dem Missionplaner)
- externes U-BEC als 5V Stromversorgung, da ich gelesen hatte, dass das Powermodul recht unzuverlässig sein soll.

Aber ich glaube jetzt, das Problem ist weniger bei der FC als bei einem Regler zu suchen. Im angehängten Video wird der Regler hinten links (ab 0:32) recht kommunikativ. Ich weiss nur nicht was er mir sagen will....

http://youtu.be/slzFlvBCH4s

Hatte dann auch noch einen Absturz und daraufhin logging + Motors eingeschaltet. Allerdings kann ich keine Auffälligkeiten - bis auf das vom Himmel falllen - finden. Aber das scheint ja bei mir bald normal...4 Abstürze an 2 Wochenenden soviel hatte ich wohl im ganzen letzten jahr nicht. :(
 

Anhänge

curzon

"alter Mann"
#20
Der Sirenen-Sound des ESC heißt, der ESC ist 'abgestürzt' und die SimonK-Software hat neu gebootet - SimonK softwaretechnisch gesprochen passiert das, wenn der Regler den internen Watchdog nicht mehr 'bedienen' kann und dadurch ein Reset des Reglers ausgelöst wird.

Ich kann das z.B. mit meinen 380KV Motoren und 40A SimonK Reglern (DYS 40A OPTO ESC, sind baugleich zu den RC-Timer 40A) am Teststand mit allen SimonK-Softwareversionen außer der alten von Sept/2012 provozieren, indem ich extrem schnelle Gaswechsel erzeuge. Meine ESC "stürzen" dann auch ab und geben den typischen Sirenenwarnton ab.

Die Ursachen können vielfältig sein. Eventuell hast du zu lange Versorgungskabel ohne zusätzliche Elkos zum ESC. Bei mir ist es die Kombination Regler/Reglersoftware/Motor. Ich komme immer mehr zu dem Schluss, keine SimonK-Regler mehr einzusetzen. Das einzige was einen Kopter am Himmel hält sind die Motoren und wenn ich den Reglern nicht trauen kann... :(

In dem Zustand (Sirene) kann man die Regler übrigens nicht mehr 'scharfschalten' (neudeutsch "arming") - die Software läuft dann in einer Schleife - man muss die Regler vorher stromlos machen.


Du kannst ja mal Tests am Boden machen: Kopter wirklich gut festbinden und/oder die Luftschrauben verkehrt herum montieren, damit sie den Kopter beim Gasgeben nach unten an den Boden drücken und dann im scharfgeschalteten Zustand mal wirklich heftig schnell Gas geben und wieder wegnehmen (und das ein paar mal hintereinander). Sollte einer deiner Regler dabei 'aussteigen' (wie auf dem Video oben), würde ich mal die SimonK 9/2012 oder andere Regler probieren.
 
FPV1

Banggood

Oben Unten