I do not actually look forward to a good surprise and the autotune will complete as the suggested method I had tried before in Sep 2022. The only differences are the PSC_xxx values and PIDs differ from the default initial parameters.
Anyway, I will still try the 4th time once I have successfully booked the space next week. If it works, then the default initial parameters do not work well for this drone’s autotune.
Fixing vibrations is key to getting a good tune
I think I could have found the causes of the vibe.y. Vibe.x and Vibe.z also improved. Ready for 4th autotune.
Autotune started and working…
Finally, autotune completed, THANK YOU so much to @xfacta . I like to know how and why you suggested/derived those PSC_XXX and ATC_xxx values.
Interesting, AutoTune allows higher ANGLE_P gains …
@xfacta
These values should not be increased beyond what Autotune suggests without careful testing. In most cases pilots will want to reduce these values significantly.
May I know the reason to double it instead?
Autotune seems to give a conservative ATC_ACCEL_Y_MAX which can lead to an apparent “overshoot” in yaw movements. Doubling or at least increasing ATC_ACCEL_Y_MAX allows yaw to respond to input and corrections in a more timely manner.
Its not critical at all, but can be useful or nice to have yaw responding in a timely manner.
Hi @xfacta
after resetting and using your suggested default values for autotune, I keep getting Altitude overshoot when the pilot takeoff, Pilot_TKoff_ALT = 200. After a few seconds, it will settle down to ± 2m.
Is it caused by one of the PSC values? Can I change back to default values?
I am also using a rangefinder for height as well. I am setting up the UA for both indoor and outdoor usage as suggested here.
EK3_SRC1_POSZ = 2 (RangeFinder)
EK3_SRC2_POSZ = 2 (RangeFinder)
PSC_POSXY_P,0.5
PSC_VELXY_D,0.25
PSC_VELXY_I,0.5
PSC_VELXY_P,1.0
PSC*XY params dont have anything to do with altitude, that would be Z-related parameters
Both indoor and outdoor selection has this overshoot. I notice not all my past logs have this CTUN.SAlt, It seems to follow Baro alt behavior. hmmm …
I thought it may be due to EK3_SRC2_VELZ set to none where no other option, but outdoor also happens.
I hope nothing to do with these settings, I did this on another UA before.
EK3_RNG_I_GATE,500
EK3_RNG_M_NSE,0.5
EK3_RNG_USE_HGT,63
EK3_RNG_USE_SPD,6
I guess it is time to update to 4.3.0 release.
Potential thrust loss and crash
Can anyone able to help identify the cause of the thrust loss during a flight? PMU, ESC, or FCU (4.2.3)?
this drone has been overall functioning well since 2022 July. Just last week, I did a very successful 25mins single battery flight indoor. Really does not understand where goes wrong.
Hey @Jai.GAY I think it would be better if you create a separate post for your case.
It’s like a problem with an ESC, maybe even a motor but you already replaced it.
You ESC settings look good in that pic.
You still have some frame twist or something going on there, motor outputs between 1,2 and 3,4 are different.
Are the motors or ESCs getting hot?
I am in preparation to upload the only timelapse video [done], the video indicates motor 4 started the entire problem. It falls back first and hit the ground. after that, it continues to climb to the ceiling and I am worried I will spoil the rental court so with no option but to kill it. Everything just happen too fast for me to think too. 102 01-01-1980 08-00-00_b4_crash.bin was a flight just before this video record and everything was as normal.
Do you suspect the old firmware issue?
No, not at all, after 25mins flight time, a hand can touch, estimated 40-55 degrees or lower. a very cold motor. ESC I am not so sure but is rated 60A (15A per arm), I do not think is an issue. The hover current for the entire drone is like 8-10A.
we will take note, we will settle it in our 2nd frame setup.
So this is the same problem you have been having for 3 months in this post?
No, not the same problem. I do not think is a problem initially, it was a journey.
the journey continues…
moved to 4.3.0, what can this value BARO_FIELD_ELV help in the overshoot during takeoff? I still see it in 4.3.0 with the BARO_FIELD_ELV default value.
This parameter is not persistent and will be reset to 0 every time the vehicle is rebooted
Have you tested 4.3.0 and/or 4.3.1-rc1?
What are the results?
Just the 4.3.0 stable release. I am outside, later I will put up the attitude graph, which is the same. Do you think the sampling rate of the rangefinder and pilot acceleration can also affect the overshoot?
[Edit]
I have to set PILOT_TKOFF_ALT to zero to temporarily to solve the overshoot. MOT_SPOOL_TIME does not help either.
4.2.3, I got the repeat Potential thrust loss, I hope such an issue did not propagate to version 4.3.x. Fortunately, with MOT_THST_EXPO,0.99, it did not crash or hard landing, 4.2.3 corrected itself and climbed back.
