Servers by jDrones

Fatal crash on a tried and tested rig. 4.0.5 / omnibus f4pro / r9mm

AP4.0.5 on omnibusf4pro on a ZOHD Dart XL, having flown many times before.
Did all the usual preflight checks – control and stabilization direction, gps lock, battery level, radio range check, cables and connectors, birds in the vicinity, traffic on a nearby village road, video in googles…

10 seconds after takeoff (more like still during taking off) I looked down to see telemetry on my Tranis screen (yaapu), a second later as I looked back at it the plane started rolling slowly to the left, not responding to commands. Hit the ground at full power, 90 degrees left roll some 80-100 meters away. The plane, as I think is obvious, is totalled and a write-off. Here’s a photo of the corpse.

Please help me understand what happened today since I can’t make sense of what the log tells me.

After the crash, back on the bench all the electronics did function as correctly – power, servos, FC…

Dataflash log

Note: the rxrssi dropping to zero after the crash (clearly visible on the log) is due to me thinking I may have used the wrong sma adapter on the R9 antenna. So removed the radio antenna to check while walking to the crash location. It was the correct sma adapter.

Many, many thanks in advance!

edits: typos

Do you have a log from a successful flight so we can compare?


Thank you!

I am very curious about the findings because I had the exact same sequence of events on the maiden flight of one of my designs a couple of years ago. Mystery was never solved. All I have left behind is a video of a graceful take off, then loss of control leading to a gradual bank to the
left, and crash. Everything was in working order during the diagnostic after the crash and I attributed the issue to a random brown out of the pixhawk or a stall due to a design flaw. I had telemetry on Taranis active as well but with the Craft & Theory package. A few months later I read in one of the Arduplane firmware updates that a brown out bug associated with frsky pass through telemetry was resolved. I wonder whether there is really a persisting issue there.

An excerpt from the crash log. This is (I think) what I need your input on to help me make sense of what happened. Or I may be completely mistaken and the reason is hiding somewhere else in the logs.

Again, thank you for your time!

I have no idea if this applies here but I came across reports in more than one place that R9MM is the one R9 receiver that tends to cause problems. Those reports made me sell an R9MM I had intended to use and get an R9 Mini instead.

This link is related to a crash and log analysis that may look like to yours.

Your log shows that Rcout C3 and RCin C3 match closely up to the crash so this is not a RC issue.
Att Yaw and AHR2 yaw does not mach closely (they do match in the good log) that may indicate an attitude estimation problem. From the above link :You have the compass disabled (with COMPASS_USE=0) and are not being careful to only carry the aircraft nose forward when moving on the ground.

@losawing Thank you for spending time on this.

Is this the mismatch you are talking about?

WRT COMPASS_ENABLE and COMPASS_USE – The compass while existing on the gps unit was not wired hence I disabled it during configuration to be both not …ENABLEd and not USEd. What difference would it have made if I just left the USE parameter to TRUE, or both to TURE given the physical unit was not connected to the FC?

Also, crash happened some 100 meters away from the takeoff location – should the time taken for the plane to get there, some 5-10 seconds, be enough for the AP to get a decent idea of where it’s headed?

It’s quite mischievous AP to be relying on heading derived from an essentially stationary gps receiver. What would be a sane method of launching compassless (could not find anything regarding this in the plane docs)?


yes, on a vertical axis the mismatch is only around 20°, that sounds to be a small value…

If you enable the compass and no wire it, I suppose the mandatory compass calibration will fail and you will not be allowed to fly.(provided arming check is enabled). I cant say what exactly means enable and use, I am just an user. Nevertheless I think it is much safer to use compass. Read carefully Tridge’s remarks about EKF yaw initialization that is conditioned to GPS ground speed.

I don’t know but wind speed is an other parameter. in the absence of compass and airspeed it is even more difficult for the controller to get a reliable heading estimation in case of strong wind.

This yaw problem estimation is just a suspicion. If I understand correctly Tridge’s advise you have to walk with your aircraft nose forward at a speed higher than 7m/s (and hope you do not get a GPS gltch…).

7 meters per second is 25km/h… I can’t really run that fast :slight_smile:
I don’t think this is the intended way to launch without a compass. In addition, many if not most of the people I’ve spoken to myself and the guys all over the internet do fly themselves, and even recommend, not using a compass on a plane. I personally am an arduX user since the 2.x days on both copter and plane and never had such an issue.
Honestly, I think the reason for the crash is something that evades both you and me, @losawing.
And you are correct, one of the elders, like @tridge, is likely having the knowledge to make sense of what the logs have to say.

Once again, thanks for your help!

Anyone, any ideas on what caused that crash?

Are C1 and C2 the elevons channels? There are significant oscillations in the altitude loss stage of the flights. Soon before it, the GPS speed has stopped to increase. Power-on stall? (not without a reason called departure stalls).

In situations like this, I always switch to MANUAL and try to recover airspeed.

1 Like

C1 and C2 are elevons, yes.

The dart-xl cruises along at ~55 km/h quite happily, and you are correct that it’s [notoriously] hard at launching sometimes but in this particular flight it just took off. Stalls like what you describe I’ve had on several occasions, them happening at the very early stages of flight – in the first 3-5 seconds after throwing the plane. Having said that, I did quite some training on the launch part of the plane and haven’t had an issue with is for like 7 months prior to this.

As per the log the plane has reached 20m/s (~70km/h) which I see as being way out of the stall speed envelope.

On switching to manual – two things (1) That thing with fiddling around with telemetry on the Taranis, not looking at the plane, and (2) by the time I realized it was going down it was too late to do anything. This and on top of that I have my mode switch on two switches on the transmitter, would have taken too long to switch to manual even if I did try. Which, while your advise is solid, I did not even have the time to think of trying.

Thank you for taking the time to help me resolve this, @maciek252

The stall is related to Angle of Attack rather than airspeed. There might be a dynamic stall if the AoA changed rapidly. Those elevon oscillations should be investigated.

Another advantage of switching back to MANUAL is that you gain back the control of throttle. I always throttle back, as the power-on crashes are causing way more damage. I’ve set it up in the way that selecting MANUAL and RTL is done easily and quickly.

If takeoffs happened to be difficult, you could give a try to the TAKEOFF mode. More efficient and provides heading control.

The stall is related to Angle of Attack …

I think it may have to do with bank angle, not aoa. And this was a tip-stall. Though my gut still kinda tells me the plane, at the time of it starting to drop like a brick knife-edge, was way out of the stall envelope. I’m saying this having launched it tens of times. Many of which even successfully…

Another advantage of switching back to MANUAL is that you gain back the control of throttle…

My understanding is that in FBWA the pilot still retains controls of the throttle in the range THR_MIN - THR_MAX. Which in my case are set to be 0 - 100% throttle… ok,were set :slight_smile:

… you could give a try to the TAKEOFF mode …

I know, just never got to that.

Here are the oscillations you are talking about, but I’m not sure what to do with what we see on the graph:

I like MANUAL setting because I don’t need to think in which mode I am - just switch in case of control loss. Also it reduces the throttle much faster than FBWA.

I think that your plane was stalled - no roll reaction to elevons moves. Airflow separated from airfoil?

Thank you, @maciek252.
If this was a stall, which I’m still not sure it was, a sneaky stall it was…

Better luck next time, I guess…

Thanks to everyone for your time!

Servers by jDrones