Hello
I need help analyzing a BIN file.
I can’t determine the cause of yesterday’s crash after analyzing the BIN file.
After starting (FBWA), the model seemed to follow the control inputs, but after a planned 180-degree turn, the model reacted unusually, and the motor apparently wouldn’t shut off.
After checking the transmitter, I lost sight of the model and switched to RTL.
The model didn’t appear at the RTL/Rallypoint position.
According to RTL, the autopilot automatically switched on the motor (RC TX Motor off) but did not respond to the pre-selected altitude of 60m.
The model then crashed to the ground with the motor running.
The altitude graph shows signal drops, which shouldn’t be the case given the flight path.
I couldn’t find any correlation between these drops and the map recording.
With FW 4.6.0 I have flown 40-50 missions without any problems, with FW 4.6.3 it was the third.
Thanks hunt0r for the tip.
I’m not familiar with analyzing the BIN file, so I have the following questions:
Why didn’t the model circle the HOME position (60m altitude / RTL/Rallypoint) in RTL mode, but instead crashed far away from it?
How can the dip in the ALT diagram (see .BIN file) be explained?
How can the kink in the MAP recording and, more importantly, the flight path itself be explained?
In case of low voltage (BATT_CRT_VOLT = 11 volts), the autopilot should also trigger an RTL (BATT_CRT_VOLT = 1 RTL)!
I’m not sure if this is a hardware problem (ALT diagram) or a software problem
(update from FW 4.6.0 to 4.6.3)?
Have you already tried? I just discovered the UAV Log Viewer webtool, it looks very good. Worth opening it and exploring your log a little to see what questions you can answer yourself.
Where I’d start with your specifics:
Why didn’t the model circle the HOME position (60m altitude / RTL/Rallypoint) in RTL mode, but instead crashed far away from it?
From the log, find (1) the home position and (2) the radius which the plane should have used to circle it. If those don’t match the behavior you see, explaining what you found + what that makes you expect vs what you observe (in the log) is a great way to ask for specific help.
How can the dip in the ALT diagram (see .BIN file) be explained?
How can the kink in the MAP recording and, more importantly, the flight path itself be explained?
Something went awry with the AHR2. (There are other estimates of altitude onboard, and they did not “zero out” like that.) I did not look specifically into it yet. Assuming by “the kink” you mean the sharp corner which precedes an unrealistically straight portion of flight, I assumed that’s merely connecting the dots which are missing while the estimator has stopped functioning. The aircraft (of course) did not actually fly that sharp-corner-then-perfectly-straight flight path.
In case of low voltage (BATT_CRT_VOLT = 11 volts), the autopilot should also trigger an RTL (BATT_CRT_VOLT = 1 RTL)!
I’m not sure if this is a hardware problem (ALT diagram) or a software problem
(update from FW 4.6.0 to 4.6.3)?
Are you saying you intended the plane to go into RTL when voltage <= 11 V is observed?
If yes, do you understand the difference between “resting voltage” and “voltage under load”? My best guess is that if 11 V was intentional, you were thinking of resting voltage while the system actually uses the voltage under load when comparing against the CRIT threshold.
I just noticed that the software reports it was version 4.6.0. You said 4.6.3. In case you thought you were flying something different than you were, that’s important!
I will take a look at the UAV Log Viewer web tool soon.
Sorry, my mistake, this autopilot has always only been in use with version 4.6.0.
I confused it with a different model/autopilot.
The gap in the elevation profile is visible in AHR2/ALT, but not in BARO/ALT!?
Something seems to have gone wrong in AHR2.
The model’s flight path was controlled and observed until the southern part of the map recording. Here, the flight path apparently matched the control inputs on the RX-TX.
What was wrong was: the motor was switched off at the RC-TX, but it could be seen that the motor continued to run (apparently BATT had already switched to RLT here).
After checking the RC transmitter, the model was no longer visible. No further control inputs were made on the RC-TX. After a certain period, the RC-TX was switched from FBWA to RTL (only).
Now, after analyzing the timing, it can be determined that RTL (14:24:25) was triggered by the “voltage under load” (<11 volts). The RC transmitter only switched to RTL at 14:24:46. Therefore, the model should have flown to the home position (RTL_RADIUS=25m / RTL_ALTITUDE=60m) at 14:24:25, but it did not.
Instead, the model entered a stable circular path with a radius of 125m. The impact was at 14:25:03.
RTL (triggered via RC-TX or BATT) had always worked flawlessly with this model until now.
Why it didn’t work this time will probably remain a mystery forever.
If I understand your log correct, than are all arming checks disabled and your GPS has no valid position information. So RTL cannot work as expected.
Also after RTL was entered due to BATT_FS the baro shows climbing up to round 80m but as you switch to RTL on your TX the baro shows decending to ground.
You said, you switched motor of by command from your TX. How you do this, is this done by some extra channel?
Hello Juergen
The safety check should be activated – will be changed.
The autopilot was activated at 14:19:09 under open sky. An engine test (ARMIN-OK) was performed at 14:19:13. The model remained at rest for 5 minutes (BIN/Bat/0/Volt) before being launched at 14:24:15.
At 14:24:25, the autopilot itself activated RTL (BATT_FS_CRT_ACT=RTL / <11Volt). RC-RTL was activated at 14:24:46 (FBWA / RTL), using channel 5 (BIN/RCIN/C5). Crash on 14:25:03
From launch, the model flew steadily from 380m(?) (field altitude 360m) to 468m and then descended steadily to 360m (BIN/AHR2/Alt). See also BIN/AHR2/Alt for BIN/BARO/Alt.
All parts were recovered and are working perfectly here at the table.
Unfortunately, this model is irreparable - crashed with 9m/sec.
Hallo Werner, all this I can read from your log. Did you move your plane between arming motortest at 14:19 till launch at 14:24 as it takes the home orign at 14:19. But you don’t answered how you switch motor on and off? Is this only done with throttle or do you have a dedicated switch?
@werhof Sounds like we’ve found several things: unexpected version, arming checks disabled, etc.
I interpret “Why it didn’t work this time will probably remain a mystery forever.” to mean that you’re satisfied, and don’t want to dig further. (But maybe that was not your intent?) Are you requesting further help at this time?
Thanks for clarifying. OFC I don’t know what happened during that 5 min period… so I guess the question is for @werhof (if they are still seeking help).
Hello Werner,
I’m sorry, but you have configured the aircraft in a way that makes complete nonsense in several respects.
As @Juergen-Fahlbusch already wrote, the first mistake is that you disabled ARMING_CHECK.
So you couldn’t have armed at all because the GPS only ever received a maximum of four satellites and had an HDOP consistently above two. This makes the GPS positions highly unreliable in the log evaluation.
Then you have set a battery failsafe so that it triggers RTL after just 3 seconds and below 11 volts (11 volts is still perfectly fine for 3s).
Now it’s getting even worse: You have activated RTL_AUTOLAND, which requires a mission with DO_LAND_START.
You have saved a mission in FC, but it only consists of a TAKE_OFF.
The cause of the crash ultimately lies in the fact that you “forced” the aircraft into an autothrottle auto-navigation mode with far too low GPS accuracy and an incorrect mission by setting the wrong parameters and, in particular, switching off the ARMING CHECK, without which this would not have happened.
I would install the current stable version and only make changes to the default settings if you are familiar with the WIKI and know what you are doing.
Thanks everyone for the information!
Of course, I’d like to know exactly what caused this crash. It’s clear that there’s a parameter problem.
Okay, there were still a few dead entries from past tests in the parameter list.
DO_LAND_START wouldn’t have activated if RTL_AUTOLAND had been set to zero.
To understand the exact sequence of events during the flight, and since I’m not familiar with analyzing the BIN file, it would be very helpful if I could get the following information:
Is the following information stored in the BIN file, and where?
Was RTL position reached?
Is DO_LAND_START active/inactive?
Number of GPS satellites
You have activated RTL_AUTOLAND, which requires a mission with DO_LAND_START.
You have saved a mission in FC, but it only consists of a TAKE_OFF.
It seems like maybe you misunderstood that statement?
Is the following information stored in the BIN file, and where? […]
Number of GPS satellites
The fact that Rolf knows you reached a maximum of 4 satellites says “yes”. I think it would be a great task for your current level to attempt using the documentation + available tools to find this yourself.
After you try for a while, if you still can’t find, post back explaining what you were able to find successfully in the bin, and how you searched for the GPS # satellites info but could not find it. (I believe you will find it, and won’t need further help with that.)
I second Rolf’s recommendation: reset to stable + default params, revisit the basics, and build from there.
