Bug in the code of the ADXL345
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Bug in the code of the ADXL345
Why is this stuff not being incorporated into the main code base?
Re: Bug in the code of the ADXL345
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
viewtopic.php?f=8&t=849&hilit=GYR_CMPF_FACTOR&start=90#p7595
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Bug in the code of the ADXL345
I have often wondered about the reason for not using float variables for the Angular calculations.
Thanks
Thanks
Re: Bug in the code of the ADXL345
PatrikE wrote: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
Last edited by mahowik on Tue May 01, 2012 8:57 pm, edited 1 time in total.
Re: Bug in the code of the ADXL345
copterrichie wrote: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...
Re: Bug in the code of the ADXL345
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.
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.
mahowik wrote:PatrikE wrote: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
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Bug in the code of the ADXL345
mahowik wrote: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.
Re: Bug in the code of the ADXL345
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!!!)
- 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!!!)
Re: Bug in the code of the ADXL345
mahowik wrote:- 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.
Re: Bug in the code of the ADXL345
People still fly multirotors for fun with standard ESC?
Re: Bug in the code of the ADXL345
marbalon wrote:mahowik wrote:- 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...
Re: Bug in the code of the ADXL345
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
On all I think level is way to high for beginners I'd go with more like 5.0/0.020/060
-
- Posts: 5
- Joined: Wed May 02, 2012 7:33 pm
Re: Bug in the code of the ADXL345
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.
My config:
ADXL345, ITG-3200, HMC5883L, BMP085
Hexa6+ (32cm Motor to Motor)
PIDs almost your defaults, a little higher Ps
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
Re: Bug in the code of the ADXL345
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)
Re: Bug in the code of the ADXL345
mahowik wrote: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!
Re: Bug in the code of the ADXL345
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