Bug in the code of the ADXL345

[Bledi]

Is someone had try it and confirm what I saw ?

[vectR]

Bledi,
I can confirm that using /8 in the ADXL345 code stabilizes the level mode.
I added this factor into my code along with acc_1g = 256.
This appears to be needed based on the data sheet which specifies using a scale factor for proper conversion of raw LSB units into g (gravity) units.
Several other sensors in multiwii 2.0 including gyros also use similar scale factors when reading raw data.
The exact scale factor 8 or 4, etc. may be open to debate, but I think something should be included in future code upgrades

[timecop]

Are you dudes running 'accel calibration' after flashing with /8 code? cause there's no way its gonna work like that with acc1G being 256.

[Bledi]

No calibration for me, just acc trim

[Alexinparis]

Hi,
With a wrong acc_1G, angles should not be correct anymore, and the value of ZACC when the copter is reverted should not match -acc_1G.
is it the case ?
The correction might be however better near 0 inclination, it's something we should find out why.

[Bledi]

yes acc_1G is totally wong and on the GUI the 3D position is false.
Division by 8 is not a solution but there is really something interesting

[Hamburger]

How does /8 compare to one of the gyro smoothing options already in MWii code?

[shikra]

I have a board with a adxl345 which has always been very twitchy / crap compared to my sirius boards. I assumed it was a bad sensor and stopped using. Will retry. I used a high LPF factor #define ACC_LPF_FACTOR (any reason that is hidden in IMU and not in the advanced config section?).

[mahowik]

Hi guys,

Let me explain what is going on

If you have a noise on ACC (because of vibrations or some other reason e.g. electrical influence) IMU takes this into account via Complementary Filter (CF) and pass this noise to PID regulator where "I" part accumulate/integrate this small inclinations (but actually it's noise) to incorrect compensations. As result you have drift or unnecessary wobbles...

By dividing the raw ACC data to 8 you have:
1. reduced angles measuring. E.g. real 45 deg will be measured as 45/8 deg in ACC. As result IMU integrator will use (and go to) decreased angles for correction and pass decreased angles to PID regulator which will produce the decreased control to the motors...
2. low sensitivity. It means if you have noise in range 1-8, it will be zero by dividing. So as result in noised configuration you have profit...
BUT in spite of some advantages, it gives fully incorrect angles estimation!!!

For noise configuration I made a complex solution a couple of months ago (which is already checked with many guys from Russian forum):
1. float LPF with 1-2Hz cut frequency used for ACC in IMU.

Code: Select all

      #define ACC_LPF_FACTOR 100
...........
      #define lfpFactor (1.0f/ACC_LPF_FACTOR)
      static float accLPF[3];
..........
      accLPF[axis] = accLPF[axis] * (1.0f - lfpFactor) + accADC[axis] * lfpFactor;
      accSmooth[axis] = accLPF[axis];

2. Gyro Weight (GYR_CMPF_FACTOR) was increased to 400-500 to take into account more gyro than acc because gyro less sensitive to vibrations...
3. set gyro LPF to 42Hz in case of itg3200/3205 (#define ITG3200_LPF_42HZ)
4. reduce Level PIDs. P=7.0; I=0.01. Where I=0.045 is to much for most configurations and produce jumps on start or unnecessary wobbles.
5. make acro PID more smooth by increasing D param, where P should be increased accordingly, because big D push and decrease P...
Good are P=5.2; D=35

For details you can find prepared 1.9 and 2.0 sketches (with predefined PID settings) here http://forum.rcdesign.ru/blogs/83206/

I hope it will kill your headache with any drift at all! Enjoy!

thx-
Alex

[Bledi]

I love your idea. I will try it because for me too the only explain for the result /8 is the noise rejection and the most important wieght of gyro

[Bledi]

@mahowik, I just test your mod ! It's really THE SOLUTION.
I just test with a CRIUS LITE on a ARwiiDrone (ARDRONE with keda 20-50s) and it's really crazy the difference.
For my first test I don' set gyro LPF, I undefined the deadzone but it's really a pleasure

[mahowik]

cool!!!

[Bledi]

A correct my misstake is not a CRIUS SE but a CRIUS LITE

[marbalon]

Hi guys,
1. float LPF with 1-2Hz cut frequency used for ACC in IMU.

Code: Select all

      #define ACC_LPF_FACTOR 100
...........
      #define lfpFactor (1.0f/ACC_LPF_FACTOR)
      static float accLPF[3];
..........
      accLPF[axis] = accLPF[axis] * (1.0f - lfpFactor) + accADC[axis] * lfpFactor;
      accSmooth[axis] = accLPF[axis];

2. Gyro Weight (GYR_CMPF_FACTOR) was increased to 400-500 to take into account more gyro than acc because gyro less sensitive to vibrations...
3. set gyro LPF to 42Hz in case of itg3200/3205 (#define ITG3200_LPF_42HZ)
4. reduce Level PIDs. P=7.0; I=0.01. Where I=0.045 is to much for most configurations and produce jumps on start or unnecessary wobbles.
5. make acro PID more smooth by increasing D param, where P should increased accordingly, because big D push and decrease P...
Good are P=5.2; D=35

I can write only few words;
1. Agree
2. Agree
3. Agree
4. Agree
5. Agree



Long version:
1. LFP for ACC and float version should be in main branch it really make difference.
2. Just agree. Gyro is really better sensor than ACC in copters and we can calculate angle using gyro corrected a little with ACC to find flat position.
3. Most gyro have LFP and should be used
4. I always set D about 50-60 for Pitch and Roll, and I really satisfied. no oscilations etc...
5. I think huge i is danger for most new users. They always start by increasing throttle very slowly, so you probably know what happened... I is only useful when someone have unbalanced quad but most users don't need this.

So i thing it is good way to solve some users problem. i have ADXL345 in one of my board and it flies without any problem with settings above for many months.

regards,
Marcin.

[Bledi]

I just finish tests with a small and a big drone equiped with CRIUS LITE and CRIUS SE. There is really a big difference even with default PID.
I think Alex and other developpers have to try it

[timecop]

I also added these same changes to STM32 port, and several people already reported improvement in stable mode.
I put several packs through my test quad with increased gyro influence / heavier filtered ACC, and it was the first time I kept level on during entire flights, it did not fight back and generally behaved very well and allowed me to do some piros and nose-in hovering!

[PatrikE]

I have made some tests.
using #define ACC_LPF_FACTOR 100
Level ( 5.0 | 0.01 | 43)

QUADX MONGOOSE1_0 ( ADXL345 )
Works much better when using /8.

Mahowik mod.
BIG difference.
But it will still build up a drift after 5 sec.
If i let it drift free it will start drift in another direction soon.
It keeps within 50x50 meters but drifs slowly around like drunken sailor.
--------------------------------------------------------------------------------------

VTAIL4 With ATAVRSBIN1 (BMA020)
Mahowik mod.
And no backlash.
Rocksteady after some Acctrim with TX.
Can only see some drift from vind.

I will do some more tests and increase ACC_LPF_FACTOR

Great mod!..
/Patrik

[Bledi]

good news PatrikE !

[mahowik]

Actually we can't avoid a little drift because there are a lot of factors like: temperature influence to gyro and acc, ESC; not ideal sensors calibrations; accumulated errors in calculations/integrators etc.
If you you wanna have ideal horizontal positioning, you need to use optical flow sensor (or GPS) with solution like here viewtopic.php?f=7&t=1413

p.s. Alexmos provided great workable solution for this. I have already bought ADNS-5050 sensors and going to try

[PatrikE]

I added Shikras driftkiller.
It set errorAngleI to zero if errorangels diffs.

Code: Select all

 errorAngleI[axis]  = constrain(errorAngleI[axis]+errorAngle,-10000,+10000);
   #if SHIKRA
   if (errorAngle > 0 && errorAngleI[axis]<0 ) errorAngleI[axis] = 0;
   if (errorAngle < 0 && errorAngleI[axis]>0 ) errorAngleI[axis] = 0;
  #endif
 

It removed almost all drift from with ADXL345.

I can actually fly in Lvelmode now...

[copterrichie]

Why is this stuff not being incorporated into the main code base?

[mahowik]

Me and ziss_dm already tried to propose (some months ago) float filter for ACC and high gyro factor in CF(complimentary filter) but it seems Alex don't like float variables in the code

viewtopic.php?f=8&t=849&hilit=GYR_CMPF_FACTOR&start=90#p7595

[copterrichie]

I have often wondered about the reason for not using float variables for the Angular calculations.

Thanks

[mahowik]

I added Shikras driftkiller.
It set errorAngleI to zero if errorangels diffs.

Code: Select all

 errorAngleI[axis]  = constrain(errorAngleI[axis]+errorAngle,-10000,+10000);
   #if SHIKRA
   if (errorAngle > 0 && errorAngleI[axis]<0 ) errorAngleI[axis] = 0;
   if (errorAngle < 0 && errorAngleI[axis]>0 ) errorAngleI[axis] = 0;
  #endif
 

It removed almost all drift from with ADXL345.

I can actually fly in Lvelmode now...

If I understood correctly Shikras driftkiller and I=0.0 are the same...
Because errorAngleI[axis] is very slow part and errorAngle is fast part which is swims near zero (i.e. when copter stabilizes its inclinations) with small positive and negative values. As result errorAngleI[axis] will be set to zero each time or very often. So actually you can get the same with I=0...
Pls. correct me if I'm wrong here...

thx-
Alex

[mahowik]

I have often wondered about the reason for not using float variables for the Angular calculations.

For gyro vector rotation and filtering in CF the float variables are used in IMU. Also it would be great to use the same for ACC LPF...

[shikra]

Hi Alex - this mod was suggested because I noticed that just after passing level, the summed up I was acting in the wrong direction for very short period until opposite angle summed up.
In practice, although this was effective I found it created a weird visual effect by sudden change in motor speed. Looked worse than the overshoot.
I started a variation of this where level I varies according to error angle and rate of anglular change. Results were really good, but then I was away travelling and sidetracked into looking into cause of drift issues. I'll get back to it soon.
In the original post I put > in wrong direction . Indeed it made I=0 !!
Actually I think most people have I a bit too high. Better to have well balanced copter and run it a little lower

hint - put it into a debug on the GUI to show how many times error angle and errorangleI are not the same side of zero! Roll the board a few times. Surprising how many cycles there are with I effectively pushing the wrong way. It's a relatively small issue - but all these little changes add up to perfection.

I added Shikras driftkiller.
It set errorAngleI to zero if errorangels diffs.

Code: Select all

 errorAngleI[axis]  = constrain(errorAngleI[axis]+errorAngle,-10000,+10000);
   #if SHIKRA
   if (errorAngle > 0 && errorAngleI[axis]<0 ) errorAngleI[axis] = 0;
   if (errorAngle < 0 && errorAngleI[axis]>0 ) errorAngleI[axis] = 0;
  #endif
 

It removed almost all drift from with ADXL345.

I can actually fly in Lvelmode now...

If I understood correctly Shikras driftkiller and I=0.0 are the same...
Because errorAngleI[axis] is very slow part and errorAngle is fast part which is swims near zero (i.e. when copter stabilizes its inclinations) with small positive and negative values. As result errorAngleI[axis] will be set to zero each time or very often. So actually you can get the same with I=0...
Pls. correct me if I'm wrong here...

thx-
Alex

[Alexinparis]

Me and ziss_dm already tried to propose (some months ago) float filter for ACC and high gyro factor in CF(complimentary filter) but it seems Alex don't like float variables in the code

viewtopic.php?f=8&t=849&hilit=GYR_CMPF_FACTOR&start=90#p7595

Hi,
ok ok, you convinced me
I will switch back to float variables for ACC filter, as the improvement seems to be very noticeable.
And I will change the default gyro/acc and lpf ratio.

It's true I don't like floats, especially when integers do very well the job (in pid calculation for instance).
In fact I which we could use integer everywhere instead of floats, manly for performance reasons.
I still think it's possible, but probably not obvious.

[mahowik]

It's also make sense to change the default PIDs for novices because OLD-wii-mans already know which PIDs they are need
- ROLL/PITCH 5.2-0.03-35 (or 6.0-0.03-40) it helps to get smooth and stable flight for most configs (tested!!!)
- YAW 8.5-0.045 it much helps to keep yaw on hold even without MAG! (tested!!!)
- LEVEL 7.0-0.01 actually big "I" (e.g. 0.045 by default for now) in most cases/configs produce jumps on start and unnecessary drift (tested!!!)

[marbalon]

- ROLL/PITCH 5.2-0.03-35 (or 6.0-0.03-40) it helps to get smooth and stable flight for most configs (tested!!!)

Did you get this values with default ESC ? or flashed with fastPWM or dedicated... ? I think it is hard to get this values with normal ESC but agree, I'm using Mystery with wii-erc firmware and this values are OK for me.

[timecop]

People still fly multirotors for fun with standard ESC?

[mahowik]

- ROLL/PITCH 5.2-0.03-35 (or 6.0-0.03-40) it helps to get smooth and stable flight for most configs (tested!!!)

Did you get this values with default ESC ? or flashed with fastPWM or dedicated... ? I think it is hard to get this values with normal ESC but agree, I'm using Mystery with wii-erc firmware and this values are OK for me.

yes, i'm using default (not flashed) Turnigy Plush 18a, but it was bought 1 year ago and I suppose it has ATmega chips insude but not Silabs...
also many people tried these PIDs (with my mods) already and in most cases it's ok with default ESC...

[shikra]

Actually I would say the acro are OK. Generally. For me thats with 5 different controllers and 4 frames.

On all I think level is way to high for beginners I'd go with more like 5.0/0.020/060

[mueller.rs]

Hi Alex (mahowik I mean, so many Alexes here )

I use your Multiwii_2_0_a0, thanks, great work, and I´m quite satisfied with it. I have only a little TBE in level mode.

I found this in Sensors.ino and asked myself if I had to select/uncomment something and for what it is used. Do I have to uncomment my ADXL345_ADDRESS? It is 0xA6.

Code: Select all

  // i2c_writeReg(ADXL345_ADDRESS,0x31,0x0A); //  register: DATA_FORMAT -- value: Set bits 3(full range) and 1 0 on (+/- 8g-range)
  i2c_writeReg(ADXL345_ADDRESS,0x31,0x0B); //  register: DATA_FORMAT -- value: Set bits 3(full range) and 1 0 on (+/- 16g-range)
  
  //i2c_writeReg(ADXL345_ADDRESS,0x2C,0x06); // rate=6.25hz, bw=3.13hz (see table 7 of the spec)
  //i2c_writeReg(ADXL345_ADDRESS,0x2C,0x07); // rate=12.5hz, bw=6.25hz (see table 7 of the spec)
  //i2c_writeReg(ADXL345_ADDRESS,0x2C,0x08); // rate=25hz, bw=12.5hz (see table 7 of the spec)
  i2c_writeReg(ADXL345_ADDRESS,0x2C,0x09); // rate=50hz, bw=25hz (see table 7 of the spec)
  //i2c_writeReg(ADXL345_ADDRESS,0x2C,0x0A); // rate=100hz, bw=50hz (see table 7 of the spec)
  //i2c_writeReg(ADXL345_ADDRESS,0x2C,0x0B); // rate=200hz, bw=100hz (see table 7 of the spec)

My config:
ADXL345, ITG-3200, HMC5883L, BMP085
Hexa6+ (32cm Motor to Motor)
PIDs almost your defaults, a little higher Ps

[mahowik]

Actually you don't need to change anything here, but if you still have some problems with vibrations you can play with internal sensor LPF:

Code: Select all

//i2c_writeReg(ADXL345_ADDRESS,0x2C,0x06); // rate=6.25hz, bw=3.13hz (see table 7 of the spec)
  //i2c_writeReg(ADXL345_ADDRESS,0x2C,0x07); // rate=12.5hz, bw=6.25hz (see table 7 of the spec)
  //i2c_writeReg(ADXL345_ADDRESS,0x2C,0x08); // rate=25hz, bw=12.5hz (see table 7 of the spec)
  i2c_writeReg(ADXL345_ADDRESS,0x2C,0x09); // rate=50hz, bw=25hz (see table 7 of the spec)
  //i2c_writeReg(ADXL345_ADDRESS,0x2C,0x0A); // rate=100hz, bw=50hz (see table 7 of the spec)
  //i2c_writeReg(ADXL345_ADDRESS,0x2C,0x0B); // rate=200hz, bw=100hz (see table 7 of the spec)

[adam]

It's also make sense to change the default PIDs for novices because OLD-wii-mans already know which PIDs they are need
- ROLL/PITCH 5.2-0.03-35 (or 6.0-0.03-40) it helps to get smooth and stable flight for most configs (tested!!!)
- YAW 8.5-0.045 it much helps to keep yaw on hold even without MAG! (tested!!!)
- LEVEL 7.0-0.01 actually big "I" (e.g. 0.045 by default for now) in most cases/configs produce jumps on start and unnecessary drift (tested!!!)

It's good helps for me, Thank you!

[igor_sk]

I have GY-80 with L3G4200 and ADXL345 on a quad, the copter flies but it twitches a little and drifts sometimes so what are correct PID settings or do I have to increase the LPF factors for the gyro and acc? I just defined gy-80 and made the adress change. Current PIDs are from mahowik