Arducopter 3.2 und "Accels not healthy"

paderborn

Erfahrener Benutzer
#1
Ich wollte heute 3.2 weiter einstellen. Vorher war ich schon 2x problemlos damit geflogen.
Raus auf die Wiese (aus Berlin) und prompt funktionierte das Armen nicht.

Mission Planner meldet: "Accels not healthy"
Habe versucht die Accels neu zu kalibrieren, aber das schlug mehrfach fehl.
(Ich hatte 3.2 komplett neu aufgesetzt, zwischendurch Arduplane geflasht. Insofern hatte ich die Accel-Kalibrierung schon neu gemacht.)

Heute Abend armed er hier auf dem Tisch ohne zu meckern.
Ich habe jetzt die Accel-Kalibrierung nochmal gemacht, aber ein ungutes Gefühl hinterlässt das schon.

Am Vorabend habe ich den Kompass neu kalibriert und EKF auf Kanal 8 gelegt. Sonst keine Änderungen.
Kanal 8 war aber aus bzw. low
Allerdings hatte ich für einen Momet den Kompass-Stecker nicht im I2C-Anschluss, sondern im CAN-Port.
Am Kabel sind allerdings nur sdl, scl und gnd belegt, ich hatte da mehr Angst um den Kompass.

Die Google-Suche ergibt nur einen wirklichen Treffer jenseits der Doku. Ein Nutzer hatte das Problem so ähnlich auch, der hatte aber wohl nach den Flashen nicht neu gestartet und es war die RC6 ( lang ist's her...)
http://diydrones.com/forum/topics/arducopter-3-2-beta-testing?commentId=705844%3AComment%3A1770356&xg_source=activity

Hatte sonst noch jemand das Problem?
Gibt es irgendeine Möglichkeit einen Hardwaredefekt weiter auszuschließen bzw. einzugrenzen.
Ich werde es wohl morgen nochmal versuchen. Mal gucken, ob ich wieder rausfahre ohne zu fliegen.
 

paderborn

Erfahrener Benutzer
#2
ich war heute fliegen und diese mal hat der Copter ohne Problem gearmt.
Flog super, etwas wackelig auf der Stelle in PosHold, aber es war auch ganz gut Wind.

Ich habe mal ein Log angehängt:
Anhang anzeigen 41.log.zip
Der Mission Planner meldet nach dem Autotest der Logs "IMU mismatch", allerdings ist der Wert nur knapp über der Warnschwelle.(Warnschwelle 0.75, mein Wert liegt bei 0.79. Failure bei 1.5)
Auch dazu findet man leider noch nicht besonders viel im Netz. Wenn ich den Quelltext richtig verstanden habe, werden die Werte der beiden IMUs verglichen.
Tatsächlich liegen im Log besonders AccZ der IMUs etwas auseinander.
Das allerdings relativ konstant...


Ich werde erstmal weiterfliegen, mal sehen.
 

paderborn

Erfahrener Benutzer
#3
Ich hatte noch einen Flug.
Ich habe die Aufhängung der FC mal festgemacht, so dass sie quasi ungedämpft geflogen ist.
Vib_Hard.png
Gedämpft sehen die Vibrationen so aus:
Vib_Soft.png

Und der Unterschied zwischen den beiden IMUs:
ACCX_IMU_Mismatch.png

Dir Vibrationen sind ok, oder?
 
#4
Selbiges Problem heute auch gehabt. Imu Warning Disabled, Problemlos geflogen.

Scheint wohl an den Temps zu liegen. In der Wohnung macht er den Käse nicht.
 

paderborn

Erfahrener Benutzer
#5
Danke!
Ich hatte den Gedanken mittlerweile auch schon.
Werde morgen mal einen Wohnung/Vor dem Fenster Vergleich machen.
Vermutlich driften die beiden IMUs bei verschiedenen Temperaturen unterschiedlich...
 

paderborn

Erfahrener Benutzer
#7
Hatte leider heute keine Muße, den kalt/warm Vergleich zu machen.
Dafür tauchen jetzt auf diydrones berichte von anderen auf, die unter 3.2 keine Accel-Kalibrierung machen können...
Im "Ready for wider use"-thread tauchte die Frage auch schon mal auf, wurde aber nie beantwortet.

Mal schauen, wa dabei rauskommt...
 

paderborn

Erfahrener Benutzer
#8
Ich habe mittlerweile mal meine Logs angeschaut und man sieht ganz gut, wie die Accel-Werte mit kälter werdender FC auseinanderdriften. Vielleicht stecken wir unsere FC ja auch irgendwann in die Tiefkühltruhe ;)

Ausserdem habe ich gesehen, dass mein log beim fehlgeschlagenen Versuch zu armen für die IMU2 konstante Accel-Werte (AccX,Y,Z≈60,56,56) zeigt. Und das auch nach entfernen und erneutem Anschließen der Stromversorgung.
Es wäre interessant zu wissen, ob man daraus ableiten kann, was das bedeutet.

Auf diydrones gibt es jetzt einen eigenen thread.
Pixhawk BAD ACCEL HEALTH APM 3.2 - collecting data

Im 3.2 released thread gab es zu dem Thema ein paar Meldungen, aber keine Lösung. Einer berichtete von Abstürzen, aber da wird auch oft Gyro mit Accel vermischt.
Der Thread-Ersteller hat Randy logs geschickt, mal sehen,was ob da etwas herauskommt.
Ich hoffe es ist nicht die Verarbeitungsqualität meines RTFHawk und es lösen sich einfach Kontakte bei Kältespannung...
 
Zuletzt bearbeitet:
#9
Hier in der Wohnung läuft alles. Stellt man den ne Stunde in die Kälte kommt der Fehler.

Steck ich den Akku drann und lass ihn 10 min. stehen = "Warmlaufen", geht der Fehler weg.

Ich habe aber eine Fixhawk und keine Pixhawk, scheint aber so genau geclont zu sein das dieser Fehler dort auch kommt.

Wie ich am Montag die beiden Videos gemacht hatte war es -1C° , Copter ging einwandfrei nach dem Warmlauf.

Diese Probleme gibt es aber auch bei den FBL Systemen, da kommt halt keine Fehlermeldung, die Driften die ersten 3 min. etwas und sind vom fliegen her nicht mehr so genau wie im Sommer.

Bei -20C° ist mir mal das Heckservo an meinem Rex-500 eingefroren, der Piezo Gyro ging auch kaum noch. War Neujahrsfliegen total "Hardcore"

Winter halt, da iss alles anders
 
Zuletzt bearbeitet:

paderborn

Erfahrener Benutzer
#10
Schau doch bei Dir mal nach, ob und welche IMU beim fehlgeschlagenen Armen daneben lag und was die für einen Wert hatte.
Wenn Du die Logs noch hast.
 

Jace25

Erfahrener Benutzer
#12
Da gibts doch beim *Hawk keinen Grund mehr für. Speicherkarte ist groß genug, dass hin und wieder aufräumen reicht und wenn dann dochmal ein seltsames Verhalten auftritt, ärgert man sich nicht, dass man keine Logs hat.

Der *Hawk steckt das Logging doch locker weg von der Rechenleistung, ganz im Gegensatz zum APM
 

hulk

PrinceCharming
#14
Ich muss mal eine unkluge frage stellen. Bin ja nun auch in der 32bit Fraktion.
Aber ich habe mich noch nicht mit den Vorteilen beschäftigt. ...ausser ekf und genug power zum loggen.
Was meint ihr mit "2imus" und welchen Vorteil hat das? Ansonsten interessante Problematik, die mich in bezug auf die Kälte draußen auch betreffen könnte.
Mfg
 

gervais

Ich brauche mehr Details
#15
Einer der wesentlichen Vorzüge des PX (und seiner echten Derivate ) besteht darin, dass man diesem doppelte ACC Sensorik spendiert hat. (Nach Rev.2.2) da hat man aus der Not (Hardware Mängel LSM303) eine Tugend (Redundanz,Fusion) gemacht. Einer der Gründe, warum der PX besser fliegt als der APM.... Das Kälte Thema betrifft indes sämtliche FC (auch DJI Produkte), das Thema des Mismatch ist aber (ausser bei Defekten) eher ein Mission Planner Problem, denn ein echtes des PX. Im beschriebenen Fall weichen die IMU zu weit von einander ab...freilich, wer definiert diese Auto Analysis und was ergibt sich daraus ?

Ich hatte heute bei 4C° mit dem AUAV-X2 :


Test: Autotune = UNKNOWN - No ATUN log data
Test: Balance/Twist = GOOD -
Test: Brownout = GOOD -
Test: Compass = GOOD - mag_field interference within limits (4.45%)
Max mag field length (566.96) > recommended (550.00)

Test: Dupe Log Data = GOOD -
Test: Empty = GOOD -
Test: Event/Failsafe = GOOD -
Test: GPS = GOOD -
Test: IMU Mismatch = GOOD - (Mismatch: 0.18, WARN: 0.75, FAIL: 1.50)
Test: Parameters = GOOD -
Test: PM = GOOD -
Test: Pitch/Roll = GOOD -
Test: Thrust = GOOD -
Test: VCC = GOOD -
 

gervais

Ich brauche mehr Details
#16
Ich habe mittlerweile mal meine Logs angeschaut und man sieht ganz gut, wie die Accel-Werte mit kälter werdender FC auseinanderdriften. Vielleicht stecken wir unsere FC ja auch irgendwann in die Tiefkühltruhe ;)

.....und es lösen sich einfach Kontakte bei Kältespannung...
In Log 41 wird die Platine aber eher wärmer...und für Kältespannung ist die Temp. nicht niedrig genug.

 

paderborn

Erfahrener Benutzer
#17
Nach einer längeren Log-Lese-Session:

In Log 41 wird die Platine aber eher wärmer...und für Kältespannung ist die Temp. nicht niedrig genug.
Danke sehr. Das log 41 ist zwar nicht das Log, auf das sich meine Aussage bezog und ich habe es leider auch nicht wiedergefunden.
Der Hinweis auf die gemessene Temperatur aber ist super. Es kann gut sein, dass ich einfach schon vorher wusste, was ich sehen wollte!

Ich habe jetzt nochmal Logs verglichen, die zuhause aufgezeichnet wurden und Logs von draussen.
Raumtemperatur:
AccZ_Innen.png

1°C Luft/BaroTemp 5-10°C:
AccZ_Aussen.png
Das ist jetzt erstmal noch kein Beweis, dass die Abweichung in der Temperaturänderung begründet liegt. Zwischen meinen Logs Innen und Aussen verhält es sich allerdings regelmäßig so.
Ich muss leider immer erst 20 min. fahren (Berlin), darum habe ich kein Log vom Temperaturübergang. Mache ich vielleicht morgen mal im Hof.

Der Blick auf die Temperatur offenbarte allerdings, dass die Baro-Temperatur Innen regelmäßig sehr schnell in Richtung 40°C geht:
Temp_Innen.png
Ist das normal?
Und das heisst natürlich, dass ich die Accel-Calibration auch bei einer Boardtemperatur in diesem Bereich mache und der Temperaturunterschied zum Flug dann 30°C ist.

Ist die Baro-Temperatur glaubwürdig? Zumal der Baro ja auch noch eingepackt ist....

Ich suche jetzt nochmal ein log, bei dem ich nach dem Aussteigen schnell losgeflogen bin.

Und zum eigentlichen Fehler, der das Armen verhindert hat...
Die Logs sehen dann so aus:
AccZ_OFF.png
IMU2 spinnt komplett.

Ich habe mal ein kurzes Log angehängt, bei Interesse suche ich gern noch ein längeres.
Anhang anzeigen 67.zip
 

gervais

Ich brauche mehr Details
#19
IMU2 spinnt komplett.
Stimmt. Ich habe es mir angesehen. ACCy tot;x,z unverwertbar. Sieht so aus, als würde die MPU-6000 (Gyro + ACC) gar nicht funktionieren. So etwas habe ich noch nie gesehen.
Um FW Fehler auszuschliessen, würde ich nochmal flashen, tippe aber auf einen Hardwaredefekt.(Der natürlich auch die Externals bzw. Lötstellen betreffen könnte.)
 

paderborn

Erfahrener Benutzer
#20
Ich flashe nachher nochmal neu.
Unter 3.1.4 und 3.15 ist der Fehler bei mir nicht aufgetreten. Und ich bin im Sommer viel geflogen.
Es gibt halt noch ein paar berichte des Fehlers und bis jetzt alle, die ich gefunden habe, unter 3.2.

Auf diydrones gibt es jetzt einen eigenen thread.
Pixhawk BAD ACCEL HEALTH APM 3.2 - collecting data

Im 3.2 released thread gab es zu dem Thema ein paar Meldungen, ...
Muss aber auch nichts heissen, es sind jetzt einfach viele mit Pixhawk und seinen Klonen unterwegs.

Leider habe ich es bis jetzt nicht geschafft, den Fehler einwandfrei zu reproduzieren.

Nachtrag:
Seltsam, dass die Gyrowerte halbwegs normal aussehen. IMU2_GyroX ist seltsam verrauscht, IMU2_GyroY und GyroZ decken sich mit den Werten aus IMU1
 
Zuletzt bearbeitet:
FPV1

Banggood

Oben Unten