Back drift issue

[nhadrian]

Hi,

finally I decided on starting a new topic since I think this problem is related to main code.
So since beggining I have a quite serious back drift, and also some drift caused by wind.
But, this is not a constant back-drift. It depends on the time, I try to explain.
So once I want to fly forward with a constant angle, I have to apply more and more stick input, other way the angle slowly decreases, even to level when I fly long enough into one direction. And when I release the stick, it has a serious back drift, and then slowly gets back into level. I have to note that in ACRO mode it flies perfectly, not any wobbles or drift, even in windy conditions. I'm using dev_20120219, but had the same with 1.8, 1.9, and any dev versions and releases. I tried to modify the acc-gyro factor from 250 to 550 (300 generally) but I couldn't completelly remove back-drift.

So I think this issue is related to the calculations. It seems to me that code integrates some kind of really small error in angle, stick input or so, during constant stick-input, and this causes the decreasing of angle during forward flight. Maybe, the lift on props or such causing the error. So maybe some compensation with MAG input would kill this.

BR
Adrian

PS.: I tried "drift killer" level implementation too, W/O success.

[nhadrian]

Any input?

[dramida]

I had the same behaviour you describe on AUTO LEVEL flying. I am using ADXL345 accelerometer.I would call this behaviour something like reverse hysteresis. More you pull the stick forward, less and less effect it has.
As i am filming, i no longer fly in LEVEl mode but in ACRO.
I keep the level mode on a switch for panic and failsafe.

[nhadrian]

So not I'm the only.... :D:D
I think we should find the origin of this error hysteresis...

[Alexinparis]

Hi,

This behavior is very dependent to the current angle calculation algorithm.
With a fast translation, the acceleration does not match the gravity.
It only happen when this attitude lasts several seconds (in this case a pure acro mode is probably preferable)
The only way to decrease this effect is:
-to increase:

Code: Select all

#define GYR_CMPF_FACTOR 310.0f

-to decrease the range [36-196] around 100:

Code: Select all

  if ( ( 36 < accMag && accMag < 196 ) || smallAngle25 )

[nhadrian]

-to increase:

Code: Select all

#define GYR_CMPF_FACTOR 310.0f

-to decrease the range [36-196] around 100:

Code: Select all

  if ( ( 36 < accMag && accMag < 196 ) || smallAngle25 )

Do you have advice for values to start with?

Previusly I tried to increase GYR CMP FACTOR to even 500, but couldn't eliminate the back drift.

[nhadrian]

And what do you think if MAG datas would be used for compensation of angle calculation? When mag is calibrated corretly, it gives the exact position in three axis.

I'm still looking for the proper accMag values, Alexinparis, could you help a bit and suggest some values for that?

[Alexinparis]

And what do you think if MAG datas would be used for compensation of angle calculation? When mag is calibrated corretly, it gives the exact position in three axis.

I'm still looking for the proper accMag values, Alexinparis, could you help a bit and suggest some values for that?

MAG data are probably less accurate than ACC in static position due to magnetic noise, but it could probably be used to compensate main drifts.
The algo to do this is another story

accMag could be constrained like this, without the second term:
if ( ( 70 < accMag && accMag < 130 ) )

[nhadrian]

Dear Alex.

I tried your suggestion but doesn't work.

But this issue is more serious than I thought till today.

The story is that today xbee and wingui worked well so I could check the datas during flight. I noticed that when this issue occurs, it looks like angle calculation goes slowly wrong since after some forward flight, angle in real will not match the claculated angle shown in GUI. Exactly the same in wind, when copter has wome windup, GUI shows it is perfectly level. So, something error integrates in calculations.

And this even exists in GPS hold!!! I had some flights in very light wind, and I can notice that overruns are partially caused by windup and back-drift!!! During overruns I looked at the monitor, and angle in real didn't matched angle in GUI! And finally, after overruns dampened, the hoovering angle didn't matched the real angle!!!!! And thats itself caused 4-5 m distance from home position!!!

So I think we should think on how to solve this, for proper GPS navi and perfect level behaviour. Currently I can't completelly understand the level and angle calculation code, but I can notice that in acro mode, real angle matches the calculated value quite well. So maybe related to level code???

BR
Adrian

PS.: telemetry and log functions in WinGUI rocks, it's more easy to debug things with this.

[nhadrian]

Any input?

[Chaosdestro0]

Interesting find, I have been having level issues where it was overrunning. I put a little bit of forward in and it will go forward quickly and if I try and put backwards in it will not respond quickly. This could be the issue that is causing this.

[ciskje]

And what do you think if MAG datas would be used for compensation of angle calculation? When mag is calibrated corretly, it gives the exact position in three axis.

I'm still looking for the proper accMag values, Alexinparis, could you help a bit and suggest some values for that?

MAG data are probably less accurate than ACC in static position due to magnetic noise, but it could probably be used to compensate main drifts.
The algo to do this is another story

There is madgwick that use a very clever approach, to help acc.
http://code.google.com/p/simplo/source/ ... unk/ahrs.h

Use only z and the projection of the vector on the plane z,y.

[nhadrian]

Hi ciskje,

Thats what I'm talking about. In this code he is using magnetic sensor to compensate the error of acc calculation. I think with a well-calibrated mag sensor (and not disturbed by motors...) could be used for something similar in multiwii code!!!
This is the same situation as thrusted acc for previous vel calculations, maybe TrustedMAG should be defined in order to use magnetic compensation part of level calculations. So this compensation should used only when mag works WELL enough, and depending on the user's choice.
Alexinparis, what do you think? Would it be hard to implement something similar into current MWI?
I'm sure proper level working (angle calculation) would help the working of GPS code and reduce overruns!!!

BR
Adrian

[Alexinparis]

Dear Alex.

I tried your suggestion but doesn't work.

But this issue is more serious than I thought till today.

The story is that today xbee and wingui worked well so I could check the datas during flight. I noticed that when this issue occurs, it looks like angle calculation goes slowly wrong since after some forward flight, angle in real will not match the claculated angle shown in GUI. Exactly the same in wind, when copter has wome windup, GUI shows it is perfectly level. So, something error integrates in calculations.

And this even exists in GPS hold!!! I had some flights in very light wind, and I can notice that overruns are partially caused by windup and back-drift!!! During overruns I looked at the monitor, and angle in real didn't matched angle in GUI! And finally, after overruns dampened, the hoovering angle didn't matched the real angle!!!!! And thats itself caused 4-5 m distance from home position!!!

So I think we should think on how to solve this, for proper GPS navi and perfect level behaviour. Currently I can't completelly understand the level and angle calculation code, but I can notice that in acro mode, real angle matches the calculated value quite well. So maybe related to level code???

BR
Adrian

PS.: telemetry and log functions in WinGUI rocks, it's more easy to debug things with this.

Hi,
The current way to calculate angle is based on:
- gyro for short term variation
- acc for long term variation

The problem is: during a prolonged forward run, the acc doesn't match the earth gravity and it causes a drift in acc calculation.
It can be tuned via adjusting complementary filter coefficient and acc reliability conditions in the calculation.
I think your problem could be tuned via a proper tuning of the current algo parameters.

The magnetic vector could be included to correct this error, but it's not so simple.
There are other off the shelf algo like Madwick's one, but the impact on the overall delay is not negligible.

[nhadrian]

I tried to raise complementary filter value to even 500.0f but problem still exist.
Or do you think even more should be applied?

[LenzGr]

FWIW, I observed the same behaviour. E.g. moving forward and then putting nick in neutral makes the copter kind of "overshoot" in the opposite direction.