Was flying perfectly well on stock PID settings but wanted to see if autotune could improve things.
About 3 minutes into the tuning whilst still on the first axis it suddenly flipped over and crashed without any warning. It looked like an overly aggressive roll command caused it rather than a motor cutting out or stalling. Conditions were calm at the time.
It had completed about 90% of a previous autotune without incident but didn't have enough battery to finish, was in the air for about 15 mins without incident in autotune mode but had to land.
Sent it up again with a fresh battery, this time without any payload to help ensure sufficient flight time to complete tuning on single lipo (New C of G was accounted for by shifting lipo position) and the crash happened.
RATE_RLL_FILT_HZ and RATE_PIT_FILT_HZ were set to 10hz as recommended for larger props and battery voltage scaling of PID gains was setup..
Spec:
Pixhawk on a 900mm Y6 frame with T-Motor 4008-18 380v motors, 10000mAh 6S lipo, 15" props.
If anyone fancies looking at the log, it would be most appreciated - I've checked a few things but still unsure on the exact cause - possibly the default AUTOTUNE_AGGR parameter which I left alone as per the instructions was simply too high?
Replies
Hi
I decide to give AT one more chance. I had bad crash i while ago. After repairs and calibrations (copter 3.3.3) i went for a flight.
First flight all good, hexa was flying smoothly..(why did i tried AT!!!!), second flight, tried at and total flip and crash right after start of first axis tune !
Log shows same fence error..?? i have no fence enabled. whats going on here??
I dont recommend to use of AT at all. This was my 4th crash when trying to complete at.
Back to work bench..last time repairs took only approx 20hours.. :D
Yes, you were quite right - I misread your reply initially as stating that both alt and circle had been breached, not just circle.
Assuming it was trying to RTL from autotune as you suggest, still not sure how different that is than manually keeping it in position with stick inputs enough to make it flip violently upside down on the roll axis.
Will be following those suggestions - 1 axis at a time with no geo fence but I still think dealing down the default autotune aggressiveness might be a good idea too.
Thank you again for the help, much appreciated.
Marco C said:
Ben said:
exactly Ben, this is what I was trying to tell you, according to your log your copter hit the circular fence and not the ceiling. Actually this behaviour wasn't known but peraphs you have set RTL in case of breaching the fence, in that case there is a quick change from what it was doing (autotune) to what It is required to do (RTL), this quick change might have disturbed the attitude of your copter.
It is just my thought...
Next time try to disable the fence, let it free to fly as it wants and adjust its position each time it tends to drift away, for large copter (2kg to 3kg) autotune can last up to 20 minutes so it is required large capacity, if you don't have this durability follow Mikko's advice and tune one axis at a time.
maybe its worth of trying, i didn´t notice that param when i was doing my tuning. i got waaay too high pid´s after AT..
Please let us know how it went with lower value, if u deside to try that.
I still doubt that too high param was reason for your crach..but what do i know..not much :D
AUTOTUNE_AGGR : Should be in the range of 0.05 to 0.10. Higher values will produce a more aggressive tune but sometimes results in gains that are too high. More specifically this parameter controls the threshold for D-term bounce back and P-term overshoot. This affects the tuning noise immunity (a higher value is more tolerant to flex in the frame or other disturbances that could trick the tuning algorithm). High values also leads to a tune that rejects external disturbances better. Lower values result in a tune that is more responsive to pilot input.
Thanks Mikko.
You are right, next time I'll have to do each axis on a separate battery, and that will help. I'll also turn off Geo Fence and fly as close to the ground as possible in case it does have an issue and crash again.
I would still like to know why the Geo Fence caused it to flip - the only idea I have currently is to turn down the AUTOTUNE_AGGR parameter to minimum?
Ben said:
Damn. OK, the error is actually correct. I've just looked at the map view in the log viewer and estimated the distance using Google maps and it looks like it was 30m from home when the error occurred.
I thought I had changed the Circle size to 500m (again for CAA compliance) but having just checked my settings it was still set to 30m from my initial testing.
So, in a nutshell, hitting the Geo Fence in Auto Tune mode can cause a flip of death - was this already known?
Thank you for the help with the logs.
Hi Marco - the thing is I wasn't outside the Geo Fence. Geo Fence altitude for example was set to 120m to comply with CAA rules (and tested repeatedly earlier in the day) - you should see in the logs I was nowhere near that altitude. I was barely out of ground effect.
The same is true in both cases, so there's definitely something else going on, not to mention that it still shouldn't cause a crash if someone did hit the Geo Fence in Autotune mode!
Are those errors definitely showing as occurring before the craft hit the ground?
Mikko - it was only tuning the roll axis at this point, it does theme each in sequence, not simultaneously.
Hi Ben,
I took a look at your log and it looks like yoor copter has breached the circular fence, in the image below you can see that in your log the only error that occurs it is related to the fence and ecode is 2
9: Fence
ECode 1: altitude fence breached
ECode 2: circular fence breached
ECode 3: both altitude and circular fences breached
ECode 0: vehicle is back within the fences
You should use autotune trying to get back the copter manually all the times it drifts away, once you are back more or less on the starting point release the sticks and autotune will restart the procedure from where it was.
Regards,
-
1
-
2
-
3
of 3 Next