RTL Crash using 4.1.0 beta1

Hello everyone…
I’ve setup an AR Wing Pro with Pixhawk1, using TBS Crossfire for RC, M8N gps and compass and loaded it with 4.1.0beta1. Did all the calibration procedures, like accel, compass and radio. Checked all control surfaces for correct movement using manual mode and stabilize/fbwa.

Since the manufacturer requires the throw to not exceed 12mm, I have adjusted the servo output (on misionplanner) for #1 (ElevonLeft) to be between 1350 and 1650 and same for #2 (ElevonRight).
Still, if I did a combination of both maximum pitch and roll on the radio, it would still exceed the max. throw recommend. Is this ok ?

I did a takeoff using TakeOff mode, it went well, and then switched to FBWA.
As I was trying to do a circle around me, I noticed that the plane wasn’t responding well to my roll requests. So I just thought about landing and was running another circle to approach the best place for landing, when I noticed that the plane was getting farther away and I engaged RTL, which made the plane not going back to home point and ended up crashing for some reason.
I got no errors on the datalog , so I cannot fully understand what happened.
Can anyone shed some light ? Was it pilot error ? Was it bad configuration ?

datalog: https://we.tl/t-vJ9NYFk85I
telemetry log: https://we.tl/t-ETUm6tymU2
Thanks

No one can take a look ?
I’d like to at least get some pointers on what could made the plane crash once it went to RTL
I see that it ascended to 106m, but can’t understand why it didnt go back to Home Point neither why it rolled that much making it crash

I can see this detail about roll after triggering RTL:


that the desired roll was about 30 degree, but the plane just “ignored”, but why?

Hi,
I did not checked the logs you’ve posted but your crash remembers me of one of my stupid mistakes with a small flying wing. I was in a big hurry to build it and go up and running with autopilot and all stuff and in the last minute I rotated the FC board a number of degrees from the initial mounting. A few days later in the field I was doing the settings having in mind the initial board mounting but somehow, by changing the right settings for servos reverse and so on, I (miraculously) managed to make the elevons to respond and compensate correctly so I could fly well in STAB and FBWB :blush:. But not in the RTL mode, the wing was flying away and it wasn’t keeping the correct altitude. Later that day I realized my big mistake and I set the correct board orientation parameter.
Maybe it is not your case, it could be a mechanical failure at your wing but some double or even triple checking won’t hurt.

Well that could be the case because indeed I had the pixhawk rotated , but I have set the correct rotating (yaw270) and performed compass calibration. It was pointing North and every other direction correctly when I checked with Mission Planner. Both roll and pitch also looked good.
But the truth is that it really didn’t seem to be going to home point…
Why?

Hi Bruno,

I was about to look at the logfile, but the webspace has expired and is no longer available. Could you reactivate the downoad possibility ?

Rolf

Sorry for that. I thought the download link would stay available a little longer.
Datalog:

Telemetry:


Many thanks @Rolf

Sorry for not looking at this log earlier.
The key to this crash is two things:

  • poor attitude tuning
  • high speed

If you look at the FBWA flight before RTL then you can see the roll and pitch control is really quite bad:


it does manage to keep flying, but with quite large deviations in attitude.
When RTL triggers then there are larger roll attitude demands:

the plane responds very poorly to these demands, especially once the speed increases (the speed increases due to poor pitch control, leading to it being nose down):

when the speed drops during the mid part of the RTL it does manage to roll a bit the way it wants, but the pitch is still too badly controlled and it gains more speed than the aircraft can handle. With an airspeed of over 45m/s (over 150 km/hr) it can’t hold attitude with this tune.
You need to do an AUTOTUNE to fix the tuning, keeping the throttle down a bit as it clearly can’t handle high throttle with the current tune.

It depends why they recommended that max throw. Based on your flight log I’d lower the limits a bit more. I also note you have them asymmetric, the MIN/MAX are set to 1300/1650. Making that symmetric would be a very good idea.

1 Like

Yeah, later by looking at the DesRoll vs Roll and DesPitch vs Pitch I understood that the plane was not responding well.
But…looking at the following image, this is intriguing me:


Here, when it reaches the RTL altitude, the airspeed started dropping (as should be expected because it reached desired RTL altitude), but the green line (Desired Roll) apears to be constant, shouldnt it be different, in order for the plane to head back home ?

They recommend that max 12mm because if one go further than that, the control surfaces start tearing apart from the wing itself.
Ok, I need to do AUTOTUNE and also reduce the max throw (keeping them symmetric), however, since AUTOTUNE behaves like FBWA and using FBWA I was having very poor control making it almost impossible to bank enought to make a circle and head to me (and that’s why I triggered RTL, because it was getting away from me)… how can I accomplish it ?

Thank you

Hi Dani,
I am not an expert in ardupilot but long years experience in RC planes learned me, that you should always try to set the throw’s in a mechanical way instead of just reducing it with bits and bytes. By doing so, you gain more resolution from the servotravel, decrease in this case the potential backlash and you increase the power to control the surfaces.

Hope this will help to improve your setup and overall flight performance.

Best regards from a rainy Bavaria,

Maarten.

1 Like

Hi @softboy,

To be able to achieve the necessary control-ability of the plane it’s always helpful to be able to fly the plane in manual mode.

For me, this saved the plane more than once.

I found another detail looking very suspicious:
I have never seen a compass readings like this.

Hope this helps.

Too much interference I guess ? But then, how could I never got any warning on Mission Planner ? That’s weird!

Hi,

It just looks wrong. Zooming in closer I see a huge variation.

you’re seeing multiple compasses in that graph. For the first compass use MAG[0].MagX.
We now use “instance numbers” for logging multiple instances of a message, and this leads to the sort of graph you are getting

1 Like

@tridge can you just give me some lights on this last doubt ?

Hi tridge,

Thanks for pointing me in the right direction. I was using a rather old version of MAVexplorer.
Shame on me…

Now I can choose the different instances. :+1:

@softboy, No worries, your compass is fine.

Hey,
I have found another thing that might have contributed to the crash.


I was using a 4S2P Li-on pack, and it seems the battery dropped to about 12.6V (~3.15V/cell), which is too low I guess ?!
According to the ESC Cut-off threshold settings, it should cut at exactly about 3.15V. So the plane got no motor/thrust at a specific point, but it then should have power again, because the battery got stabilized , or was that too late for it to recover and that’s why it starts losing altitude ?

Does this make sense ?

3.15V is not too low on Li-Ion, with good cells you can go down to 2.5V (but then it really is over).

Definitely disable the ESC voltage cutoff completely, it makes no sense anyway, as there is constant voltage monitoring built into AP. Protecting the battery while potentially losing the whole plane is a bad deal. :wink:

Yeah, I know for Li-ion it’s not too low, but since ESC cut-off voltage was set as default for that same 3.15V, I guess that contributed to the crash.

What kind of ESC was it? The ones I have always came with voltage cutoff disabled.

Hobbywing Skywalker 50A ESC : link