Baro problem or PID? [semi-solved]

[jet]

Hi, EX_TRUE.
Not yet.
I had tried various AQ6 boards, ESC (not ESC32) and frame kits.
However, this problem still existed.

So, I would try two methods including:
1. Changing to real X-frame. I am waiting for my new frame kit.
2. Adopting Quatos firmware and ESC32.
I would post my results when this problem was resolved.

[aBUGSworstnightmare]

[jet]

[EX_TRUE]

I have read many subject,
it seems that there were many people have met this problem and they can't resolve by tuning the pid values.
Is it because the problem of control or sensor problem.

[jet]

[EX_TRUE]

Hi, jet

Today, I tried the old version of AQ firmware, ie FW.V7.0-EXPR r416 b1794 HW .6r1,
the quad did not drop a lot as before. That's quite satisfied.

I check souce code changed of AQ, it added the alt_ukf.c and alt_ukf.h which use accel and baro kalman filter
to get ALT_POS for altitude control(gps hacc > 0.8) since r428.

I wonder if these changes would do badly to altitude control.

Thanks.

[jet]

Hi, EX_TRUE,
That's interesting.
I did not try the old firmwares yet.
I will try the old firmwares tomorrow and let you know my results.
However, if the old firmwares work well for altitude control, we may face the similar problem in the further firmwares .
Thanks again.

[jet]

Hi, EX_TRUE.
You are correct!
Comparing to 1848 and 1952 firmwares, when I used 1794 firmware, the altitude hold was good.
If Quatos was still poor for altitude hold, using old firmwares may be a solution ><....
Thanks again.

[chschmid]

These changes where introduced to allow a calm transition from AH to PH. In the older FW people reported a heavy jump in alt when the 3D lock set in in flight.

Cheers
Christof

[jet]

Hi, Christof
Thanks for your reply.
I believed that some bugs were fixed in new firmwares.
However, I had difficulty on getting better altitude hold in the latest firmware.
This issue may be considered in the further firmware.
Just a suggestion..
Thanks again.
Jet