I have a pretty spectacular crash I would love some help analyzing. I was doing the ~4th terrain following mission. I don’t think terrain following is to blame though. I have the log in the link below. I’m still working on editing and uploading the video of it. It contains clipped trees, undesirable barrel rolls, and a smoking motor.
Besides finding the primary cause of the crash, I was also wondering why didn’t crash detection work? AUTO mode just continued to try to fly forward until the motor caught fire…
For now, I just have the log. Key points:
10m 31s: A wild loss of control followed by last second recovery.
14m 20s: A wild loss of control followed by last second recovery.
17m 23s: A wild loss of control followed by a crash. https://s3.amazonaws.com/realsentrygun.com/uploads/2021-08-27+15-46-36.bin
I haven’t looked at your log but the video looked good and I’d just like to say 1.5m sounds pretty good to me. Once the flair is started the roll is limited by LEVEL_ROLL_LIMIT. So the plane doesn’t have much ability to adjust because it’s trying to keep the wings level for landing. Between that, and just general GPS error 1.5m seems pretty reasonable. IMO, If you need tighter you will have to have your tuning spot on, and maybe need to look into upgraded GPS or RTK system.
Sorry to hear you’ve had a crash. I’m looking at your log right now. Each of the times you’ve mentioned is coupled with a radio failsafe. But I don’t know if that’s a cause or result.
I think this might be over my pay grade. Every time I have an idea or a question I end up proving myself wrong or figuring it out.
The one thing I wonder, is there any chance the plane is stalling? Each time the speed 7 or 8 m/s. (again, not sure if this is cause or effect)
I’ll keep looking at it, but might have to have one of the smart guys step up to solve this one.
That was my guess. It always rolls hard right. Maybe the right right wing is tip stalling? But why is it only happening on this flight, and why is there so much time in between incidents?
Also, the one thing that changed before this flight was I disconnected the red wire from the ESC servo lead, so that there wasn’t a conflict with the H743-WING BEC and the ESC BEC both supplying power, per Matek’s recommendation.
Another thing that changed is the flap trim. I have been gradually adjusting the right flap up, and adjusting the leftt flap down. I would get the average RCOU.C1 from the logs and keep adjusting the flap trim with the goal of getting the average aileron position to be 1500 (centered) during periods of level flight. At the time of the flight in the log, I would estimate that the right flap was up 2°-5° from center and the left flap was down 2°-5° from center. While this may have helped with the aileron average position, I am thinking it also contributed to wing stalling, especially since the DJI air unit is on the right wing.
I had a look, and the biggest issue with the setup of the aircraft was the very low TRIM_THROTTLE. When you are flying without an airspeed sensor then TRIM_THROTTLE is the most important control for how fast the vehicle flies which means how close to stall you fly. The TRIM_THROTTLE value also matters when you do have an airspeed sensor, but it is much less critical in that case.
The log shows that TRIM_THROTTLE was set at 10%, but it is also very clear that the aircraft can’t maintain level flight at 10% throttle. A more suitable value would have been at least 25%.
So what happened is TECS kept reducing throttle (and thus airspeed) as much as it could to try to reach the target set in TRIM_THROTTLE. That put the aircraft close to the edge of stall.
The first stall happened while flying downwind. Likely there was a gust from behind which pushed it over the edge.
The same pattern then repeated:
TECS lowers throttle, striving for the TRIM_THROTTLE target
airspeed drops while flying downwind
aircraft stalls
throttle is raised while recovering
Note that this is an inherently unstable setup. You may get away with a too small value of TRIM_THROTTLE on one flight and not on the next flight. You need to factor in some margin to make it reliable.
I notice that the previous log of yours that I looked at (2021-08-18+19-14-40.bin) had TRIM_THROTTLE at 50%.
Cheers, Tridge
I have it set to 10% because I’ve been doing a lot of efficiency analysis and the results were showing that the slower I went the more efficient the aircraft was, in terms of distance traveled / watts. I have been getting away with TRIM_THROTTLE at 10% for at least four flights now. One of those flights was an hour long. I agree that I should set it to something higher. I noticed during analysis of previous logs that the average throttle was 45% (even though I had it set to 10%). Based on that, I’m thinking 45% is a good place to start. I don’t think this was the primary cause of this crash though, just a secondary contributor, since I have been able to get away with it for multiple flights up until now.
I’m thinking my gradual flap trim adjustment likely pushed the fragile stability that was being maintained over the edge. The higher flap angle on the right wing (versus the left wing) probably causes it to stall more easily, along with the weight of the DJI air unit.
I will have the video uploaded soon and I promise it will be pretty interesting to watch
Wow, I don’t think interesting is the right word. That second recovery was amazing(lucky?)!
Notice that just before each “event” the prop stops. Looks like 10% was probably below the ESC’s minimum speed, and possibly increasing overall drag. Now the plane is slowing down and the even though the prop is speeding up again through the stall, it’s in recovery, and trying to get things back under control. Likely the combination of flap and the low throttle setting together pushed it over the edge. I would bet, that if there was enough throttle to keep the motor turning (15%?) that the plane might not have fully stalled.
I just test beta 5，and found a issue，hope can be fixed，the mission planner can’t display parameter tree after update to firmware 4.1 beta 5，the FC is matek f765wing，and the matek H743 also have the same problems，mission planner have been update to latest version.
I just tested the latest missionplanner beta with a MatekF765-Wing and plane 4.1.0beta6 without any issues.
Can you explain your environment? Are you connecting over a radio or via USB?
If you could also share a tlog from MissionPlanner showing the error that may help. Typically the tlogs are here:
it is a file like this:
the tlog should show us the attempts of MissionPlanner to download parameters
I had a crash tonight after doing autotune on new airframe 4.1.0beta5 - just its 3rd flight as I was waiting for a calm day to run autotune after building this plane for a friend. The autotune seemed to go OK, but after this completed I was in cruise mode and the plane started diving towards the ground. I could not recover it and ended up flicking to FBWA, but it was too late, plane hit ground hard and was badly smashed. Ejected the entire contents through the nose of the plane in the process!
This is/was a Zeta fx79 with Matek h743 board running Plane 4.1.0beta5.
Strangely I had a similar issue a few days ago on the second flight. I ended up flicking in to manual mode and managed to recover the plane before it hit the ground.
Here is a link to the log for tonight’s flight - which includes the autotune and the crash. Any help/advice based on log findings would be awesome. Thanks, Paul
It was outputting more and more up elevator while it was nose-diving, until it maxed out. Seems like a hardware/servo failure, or the plane was going too fast and the elevator couldn’t handle it. It was going 80mph when it crashed.
Thanks for the insight guys. I have to wonder what led the plane to nose down in the first place in Cruise mode. On inspection, the servos are working fine - even now after the crash that appears to be true.
I also noticed in cruise mode that when I pulled a turn the plane would nose down significantly even in wide/slow turns. The previous flight I mentioned, the plane did a similar nose dive and I was only able to recover it by flicking to manual mode, missing the ground by inches! If the servos were ineffective, then I would not have been able to recover in manual. Think the recovery was a fluke to be honest!
I also notice that since the autotune, on the ground in FBWA when I adjust the plane’s attitude by hand, the elevons are incredibly twitchy in response to this. I am used to them reacting quite smoothly on my other models, so find this strange.
Edit: I found a YT video which explains the exact issue I am seeing with the fx79 nosing down into an uncontrollable spiral of death, and identifies the cause (see between 1m30s and 2mins): https://www.youtube.com/watch?v=zkSxvZfZlLU
As he explains in the video, its possible to recover from this in manual but leaving the flight controller to handle this causes a crash.
Hi Tridge, newbie question about versions. Sorry if this is the wrong place for this, if so please set me straight:
I’ve been following the post getting ready to try the “Beta” (assume newest) in my brand new PixRacer R15 that is still in it’s box.
But when I look in the downloads folders, I see a build under "2021-09 and one under “latest” that seems to be for version 4.2.0. Is it possible that “beta” is the almost ready version of what will become the new “stable” version - 4.1.0, while the daily builds under 2012-09 and latest are actually working ahead on the next version? Do I have that right?
yes, the beta is here: https://firmware.ardupilot.org/Plane/beta/
what you see under latest has a lot more development that is not going into the upcoming stable. That will form the basis of 4.2.0.
We do backport things from latest to the stable release on a case by case basis as well. So some things in latest will make it into 4.1.x as we do point releases.
The current 4.1.0beta6 is very close to 4.1.0 stable. I may in fact re-release it as 4.1.0 stable if I get some good test reports on it and no significant bug reports.
Cheers, Tridge
