This was my first sortie on this plane with Ardupilot;
First flight I did the Autotune and tested RTL fine.
2nd flight I launched manual again, then RTL while putting the goggles on, and figured I would watch it play out as it climbed to the set altitude; that’s went it tripped and started nosediving into the ground while I watched in disbelief lol
OK after having a good look at all the data I have some thoughts on what may have happened;
1. GPS issue?
While the HDOP might have been high and the log shows some fairly large discontinuities in the path, I don’t believe it to be the main cause; simply because
Requesting an unattainable position can’t possibly lead to the wing crashing alone; that’s what the guardrails like max bank angle and min loiter radius are for right?
GPS Alt appears to track fairly closely with Baro alt, and correlates well with the DVR, disregarding faulty altitude data such as too high reading making the wing dive to reach setpoint.
2. Parameter issue?
This wing flew great as is in Inav, I’ve tried to carry over most parameters, however I missed a possibly major one, the loiter radius; I left it default to 60 whereas I had it at 100m before
This has never been a particularly agile wing, in fact I always found the pitch quite lacking in manual vs the crazy roll rate
After autotune it behaves quite a lot better on Acro in fact, possibly offsetting some of that authority?
Either way, could it be possible that the wing had too little pitch authority to maintain a 60m radius at 45deg bank angle? so it kept raising throttle to attempt regaining altitude?
I’m reading that if the wing can’t maintain the WP_LOITER_RAD parameter then it falls back to the ROLL_LIMIT_DEG
But even then this can’t possibly lead to that spiraling condition? or is lowering roll as another fallback to maintain altitude not an option?
Thank you for reading, looking forward for some feedback!
I did manage to recover and even repair the wing btw, all components too except from the USB adapter and the battery that must have traveled to another dimension.
Hi @Fractal. A couple of us on the dev team have now taken a look at your flight logs and footage. We enjoy looking at issues and look to provide constructive feedback. Obviously, we appreciate you taking the time to post and look for feedback, and we are happy to help where we can. However, to the point I had made to you on discord, to which you had “eyebrow raised emoji”-reacted my comment but gave no response, we need to maintain our expectations on conducting safe and legal flight test.
I don’t claim to be an expert on Taiwan’s regs here, but I’m not aware on how you could fly privately over a bunch of private property and city streets with a FPV drone… for most cities this is strictly illegal and is considered a safety risk and would require permission and a strict flight plan… it doesn’t seem to be the case here. The footage and logs are damning, it appears that you weren’t flying in a way that follows Taiwan’s laws on property set backs, and were flying over moving traffic. While unfortunate that you lost the plane to the tree, it could have been far worse and so we ask that you review the regs and prepare your next flight accordingly.
Looking through your parameters file, I don’t see that you had disabled any failsafes. Looking to the second flight log, the state estimation was no good. For good localization and corresponding automatic control, plane requires the aircraft to be in a stable somewhat steady flight state for 10s of seconds before switching to automatic modes. The flight time of the 2nd flight was less than 30 seconds including take off and crash. You can see that the position estimate of the plane jumped during the short flight before hitting the tree… RTL would have no chance to recover from something like this near ground and terrain. There is a subsystem error code suggesting that something went wrong with the barometer.
For next time, make sure the plane is in good control and flying well in manual and/or FBWA before testing out a feature like RTL. RTL assumes that the plane is in a reasonably stable flight state in order to take control and return to the loiter point and radius. Its not designed to work well immediately after take off or in a critically stable state.
I didn’t see these last night when I was reviewing the logs. I think your first point on the position being unattainable is what had started it, because the position reference itself was way off. You start the 2nd flight going from manual to RTL almost instantly and near terrain. GPS lock takes some time and is prone to changing quickly when near the ground. This ignores the effect of missing compass reading, which could help things converge if biased for. Otherwise, you are at the mercy of a quick GPS lock with sudden discontinuities because of measurement changes. Also, RTL has no logic to avoid terrian like a tree. For these reasons, the plane would have to be well up and away from the ground with good GPS lock and estimate before it would be safe to change to an automated mode like RTL in order for it to fly well without incident.
To your 2nd observation, the baro signal was discontinuous, it has two jumps in it. As a result, the AHRS estimate itself was compromised, so ArduPilot’s state estimation in turn jumps. These things can be recovered when well away from the ground with good control limits and stable flight, but near ground and terrain while in a very dynamic phase of flight (thrown take-off) can make the difference in losing control and hitting a tree.
Thank you for your concern on this flight safety; while I agree the spot and setup may not have been ideal, it is our opinion that the risk was managed all the way through as the plane was let go in a safe predicted trajectory but was fully prepared to switch back to manual the instant that would not have been the case anymore.
As for the regulatory part of your inquisition I would rather not discuss given your admission to not being an expert and your assumption of our clearance.
That being said, lesson learned we’ll find a more open spot to test automatic features moving forwards
Now back to the issue at hand,
So you mean to say everything might be pointing back to the too short GPS sample before triggering RTL?
1-But then, how is that much different from an autolaunch switching to RTL after hitting the fence?
Especially with autolaunch being an automated flight mode; how would it get it’s bearing right from launch.
2-The baro and gps raw alts appear to be tracking pretty well
How can simply requesting an unattainable gps position cause a wing to disregard max bank angle and altitude safeguards?
I’m just trying to understand if there may be some parameters to change or if the wing needs a little more of a tune up;
We’ve already increased the servo mix to bias more pitch and increased the loiter radius to 100m; see how that does --at higher altitude over an empty field ; )
tldr: Should all else fail, shouldn’t maintaining altitude take precedent over everything else such as:
IF WP too close/unreacheable AND loiter_rad reached AND roll_limit_angle reached AND full pitch deflection reached AND full throttle reached AND still losing altitude, THEN reduce roll angle to allow more pitch back into the mix?
