Please help analyse a crash log

ArduPlane Plane 4.5
1

The log is from a fixed-wing model with a Matek F405 FC using the current Aruduplane. After waiting for GPS fix the model was armed and the flight took off in Manual mode but was quickly switched to Autotune since this was the model’s first flight. After an eventless flight doing my regular circuits including a few extreme stick movements I turned to land at about 10 minutes. While turning left onto final approach at guestimated 60ft heigth the model suddently put its nose down and dived vertically to the ground.

All components still respond to my transmitter input, and the only odd thing I an see on the graph is that Des Yaw is a straight line whereas Yaw is all over the place between 0 and 400. I was inputting some rudder to assist with turns, but not to the extent shown in the graph.

Model B after fence type changed to altitude 120m.param (18.9 KB)

2

Moved to Arduplane 4.5

3

> Aircraft with a forward center of gravity “may” fly poorly, those with a delayed center of gravity fly only once

.

image
image1530×768 92.5 KB

In your case the center of gravity was retarded, which does not imply that other factors also contributed to the accident.

4

You comment that you entered AUTOTUNE mode and that it was an uneventful flight.

It is true that you entered AUTOTUNE and started the ROLL setting but did not finish it, and you did not start the PITCH setting. That doesn’t sound uneventful.

image

Not only did you enter AUTOTUNE mode, the entire flight was in AUTOTUNE mode. But at no time did you make the movements in PITCH and ROLL for the autotune to be performed.

image
image1533×772 176 KB

1 Like
5

I’m familiar with the adage about flying badly or flying once :laughing: In this case the centre of gravity was correct as per the design, and the model did seem to fly very well, if perhaps a bit slow to turn, right up until the crash.

But I don’t understand how I could start but not finish a ROLL setting: From the wiki I thought all I had to do when in Autotune mode was to make some full-stick movements left and right (which I did) and fore and aft (which I also did) and autotune would make the appropriate adjustments for ROLL and PITCH. Have I misunderstood the process? Did leaving it in autotune mode (I liked the stability it gave) for the whole flight invalidate the tuning process?

In the future can I tune manually as I have done for my helis, by flying in a stabilised mode, making full stick movements, and then comparing Roll with DesRoll, etc.?

6

I limit myself to commenting on what can be seen in the logs.

Here are the movements of the roll and pitch controls. As you can see, you can’t see anywhere the alternating movements from maximum (2000us) to minimum (1000us) in each of the axes (roll and pitch).

In roll you went from 1100us to 1500us. While in pitch it was from 1300us to 1500us.

image
image1521×762 157 KB

7

Set ARMING_CHECKS,1

Make sure there aren’t any trims set up on your radio that are giving you the wrong impression of where the sticks are, because the log is only showing stick inputs that are mostly below 1500. I have it in my mind you’ve been around RC planes and helis for while. Are you using flight modes on the radio? (not just ardupilot ones) Because the trend really changes when you go from manual to Autotune.

RC_Input_1-4
RC_Input_1-41200×600 83 KB

Autotune on planes is different from copter or heli. You can fly around all day in autotune mode, it’s just like FBWA. So there shouldn’t be any negative issues there.

As for the crash, I’m going to suggest another theory here. I noticed that both the GPS and baro both show the airplane in a climb (they agree the plane isn’t close to the ground) and there is resonable speed The pitch and roll show the plane in a shallow turn, reasonable level. Then everything ends. There’s no data after that point. Is there any chance there was a power failure on the plane? Just something to make it go dark? Bad connector or solder joint? The battery voltage looked okay. It took a dip during takeoff, but recovered. Might just be coincidence that at that moment the last correction in the elevator was a nose down correction that when held pushed the plane into the dirt. Usually if there is some kind of mechanical or aerodynamic failure the log will show the dive, but I don’t see it here.

GPS.Spd
GPS.Spd991×600 31.4 KB

1 Like
9

I see what you mean about the recorded stick movements, but they don’t match what I was inputting: I’ve been around RC for 40+ years, and around FCs including Ardupilot long enough to know that the transmitter should have no trims or offsets or anything. During take-off and climb-out in manual mode it was clear that the control surface movements were far too great, so I switched to 50% rates on the Tx to calm it down. I then switched to autotune and shortly afterwards switched the rates back to 100%, where they stayed for the remainder of the flight. Could that change in rates have confused Arduplane?

The lack of data beyond what seems to be my final turn onto landing approach – though that could be a previous turn – is also odd. The FC has no SD card slot, so could it have run out of memory during a 10-minute flight?

Thanks Lano and Allister for your input. I’ll check the Tx setup, and the Tx calibration in MP as soon as I can, and report back.

10

First, to answer an earlier comment; I excluded several features which I don’t have in my setup, such as hardware safety switch, rangefinder, camera from the arm checks, resulting in the value of 144622.

I’ve just done some checks in MP and find that all controls appear to be working correctly: In the Radio Calibration screen the Roll high, mid, and low figures are 2006, 1495, and 982 when the stick is moved between extremes; for Pitch it’s 2018, 1505, 994; and for Yaw it’s 2018, 1505, 994. In the Servo Output screen each channel ranges from 1100 through 1500 to 1900 as the sticks are moved. As final confirmation I set logging to disarmed and moved Roll, Pitch, and Yaw sticks to extremes, resulting in the attached log display.

With the transmitter rates set to 50% the Servo Output values were 1300, 1500, 1700 for Roll and Pitch. Yaw is not affected by the rates setting.

Clipboard01
Clipboard011366×768 91.6 KB

Finally I checked the monitor on my Taranis X9D to verify that each stick is giving the desired output without any trims or offsets.

I accept that power failure is always a possibility, but in this case I tend to rule it out because (a) I could hear the motor running as the model was crashing and (b) my Taranis only gave a ‘low signal’ (not ‘Telemetry lost’) warning when the model hit the ground, but showed a good signal as soon as I started walking towards the crash site. Also, power failure does not explain the RCIN anomolies that Lano highlighted earlier.

Looking at the RCIN log again, I note that at about 14:36 there are extreme + and - movements of each major control, which must be when I deliberately moved the sticks to their full extremes for autotune. Also, I can’t be sure, but I think the logging actually stopped a couple of minutes before the crash. The log shows the model was armed (and serious control input started) at about 14:32. My flight was 10 minutes (I time my flights by the Taranis timer), but the log has stopped about 8 minutes after arming, during what looks like smooth controlled flight.

Edit: I wonder if the apparent lack of above-1500 RCIN values could be because I was only flying a left-hand (i.e. anticlockwise) circuit which didn’t usually require any right aileron movement? I’ve just looked at a log from one of my helis, which has never given any sign of trouble, and the RCIN traces are very similar :thinking:

11

Can you test how big a log will get on your FC? Enable pre-arm logging and just let it sit on the bench for half an hour. The fact that the file size is around 16MB makes me think that it possibly maxed out the dataflash, but it would be good if you could confirm that. If you can create logs larger than 16MB you might have an issue with your FC or power supply.

2 Likes
12

Good point Oli. I’ll have to do that tomorrow.

13

A very frustrating afternoon! Logging with this particular board is very erratic to say the least: I set logging to disarmed and connected the board with all accessories to my laptop’s USB socket and left it for half an hour. I was able to download the file using MP, but when I tried to read it I got the following message:-

Clipboard01

I then deleted all logs and did a further 5-minute run, and was able to dowload and view the log using MP, as normal.

I then did a 10-minute run, disconnected and reconnected, and saw that there were 4 log files, including one that was in progress, but when I tried to download the 3rd file in the list (presumably the 10-minute one) with MP I got the following message:-

Clipboard02

So I disconnected and reconnected again, expecting to now see 5 log files, but there was only one – the one that had just started when I reconnected.

Finally with the Matek FC, GPS, and Rx connected to the USB port I calibrated the compass (Large Vehicle MagCal) with the ensemble on the bench, and with the Tx switched on and bound to the Rx, I set LOG_DISARM back to 0, deleted all log files, and I was able to arm and then disarm 12 minutes later, to simulate a flight. When I then went to check the resulting log file this is what was displayed:-

Clipboard03
Clipboard03943×442 41.9 KB

So I couldn’t review it because of the error message, but 246 bytes is far to small for a 12-minute flight anyway.

I’ve now concluded that (a) I’ll never be able to disagnose the cause of my crash because the log file was curtailed before the end of the flight and (b) there’s something wrong with my Matek board as evidenced by the logging discrepancies :frowning_with_open_mouth: Thanks anyway for your inputs.

14

When the arming checks are set to 1 any of the devices that are not activated (safety switch, rangefinder,etc) are ignored and it doesn’t stop the checks.

That’s very possible and would make sense. But it conflicts with the earlier comment

So you can understand our confusion when looking at the logs.

I can’t offer any suggestions regarding the logging flash limitations. I don’t have experience with those boards.

15

What exact board is it?

16

Arming checks only need to be disabled for failing items (that you are aware of and accept the risk) otherwise checks for items not in use are skipped or pass.
So everyone should always have ALL

17

The board is Matek F405-WMN. I’ll take your advice regarding the arming checks setting. I had thought that by removing some checks I could save memory.

From Lano’s graph in the Jul 29 post, ‘normal’ + and - movements can be clearly seen during the manual mode at take-off, and brief full-range movements can also be seen at about 10:00:000. So that might be correctly reporting a flight which was all left-hand circuits. But what could cause the apparant large discrepancy between Des Yaw and Yaw?

18

I had tested the logging on the F405wmn some time ago. With empty memory and default logging settings (only LOG_DISARMED=1, so that logging starts without arming), about 15 minutes are logged, then the 16MB memory is full and logging is terminated. The log file can then be downloaded and is not corrupt, so it is simply not logged any further. The following messages are displayed in mission planner:

17.12.2023 15:40:31 : Chip full, logging stopped
17.12.2023 15:40:43 : PreArm: Logging failed

With reduction of the logging rate (set LOG_BLK_RATEMAX,10) to 10Hz you can log for about 25-30min, at 5Hz 55-60min.

If the memory is full while older log files are in memory, these are deleted (the oldest first) and logging continues without interruption.

2 Likes
19

Hi Allan,

in manual mode and in FBWA (+ Autotune), FBWB there is logically no desired yaw of the autopilot. The desired yaw is set by the pilot in these modes.

Everything else has already been written. The memory was just full, the log file has 16,257,024 bytes and stopped recording (minutes before the crash).

To prevent this from happening to you, I recommend flight controllers with an SD card.

To prevent this from happening to you, I always recommend flight controllers with an SD card. Otherwise I would try @jreise-d Jörg’s recommendations.

Rolf

2 Likes
20

I agree 100% about using FC with SD card in the future. I overlooked that feature when I ordered the F405WMN. It won’t improve my flying, but at least it will give me a better chance of finding what I’m doing wrong :laughing:

Thank you for that insight. That explains the missing files and also gives me the opportunity, by changing the LOG_BLK_RATEMAX, to at least record the last flight of the day in full.

21

Your compass calibration is good enough. However, I attach a calibration that makes it more optimal.

The Yaw control loop only works in ACRO mode. This is the reason for not having values in ATT.DesYaw; the system does not demand any Yaw unless you fly in ACRO mode.

MAGFit (13).param (357 Bytes)