To alex: ACC drift Issue: a bench test:

jevermeister · Post by **jevermeister** » Mon Oct 31, 2011 10:26 pm

Hi Alex,

I did some testing today:

The setup is as follows:

Flyduino v2.1 Genuine WM+, BMA020, BMP085, HMC5883L, QuadX, SumPPM, HK SS18A ESC, eMax CF2822
I have my Copter stationary on the table and pressing it down while I power up the engines in acro mode/hover mode

1. Test: Multiwii 1.8p2 with imported Stability mode from MultiWii 1.7
2. Test: Multiwii 1.8p2 standard
3. Test: Multiwii Dev20111029 standard with trustedAccZ disabled
all PID etc are the same.

1. Test (old stab 1.7) A: Engines off

1. Test (old stab 1.7) B: Engines on

2. Test A: Engines off

2. Test B: Engines on

Remember: I am holding the copter flat on the table so absolutely NO real drift is happening.
I notice the decrease of AccZ while powering up - this is what you already mentioned and tried to fix in the current dev.
You can see that the copter thinks he is tilted to left front, so he would try to correct it by increasing throttle to that motor if he is in hover mode.
I also noticed, that the Mag is 90° off if I use the old stability mode. (I did no recalibration after uploading 1.8p2 standard)but that is corrected in 1.8.
While doing the test flights with 1.8p2 standard I noticed that the copter is drifting to right rear - so what I found here is absolutely expected!
flying with 1.7 stab mode is far better.
So why is AccZ doing this strange stuff???

3. Test A: Engines off

3. Test B: Engines on

As far as I can say it until now: I think the drift issue is fixed in the current dev...
I did some flight tests in my basement and the results look very promising, the drift seems to be eliminated and the copter behaves very smooth, it is way more flyable than 1.7.
I managed ot land on my desk and fly through my doors. COOL!

I hope these results help you in tracking down the issue for sure Alex!

Should I do the same test with the current dev and trusted AccZ on or is it unneccesary for you?

Nils

copterrichie · Post by **copterrichie** » Mon Oct 31, 2011 10:41 pm

I really would like to see this same test done with another Accelerometer.

jevermeister · Post by **jevermeister** » Mon Oct 31, 2011 10:45 pm

send me one ;-)

But after the test I WILL keep it ;-)

ziss_dm · Post by **ziss_dm** » Mon Oct 31, 2011 10:54 pm

Hi,

Just want to clarify couple of things:
1) not TRUSTED_ACCZ is workaround for level mode for ACC with less than 30% precision
2) It is not solving problem it is just hiding it.
3) With not TRUSTED_ACCZ you cannot use MAG and Alt. Hold.

regards,
ziss_dm

jevermeister · Post by **jevermeister** » Mon Oct 31, 2011 10:57 pm

ziss_dm wrote:Hi,

3) With not TRUSTED_ACCZ you cannot use MAG and Alt. Hold.

Thanks for the info

that is sad news...

I wonder what is causing this mess..
maybe richie is right and the ACC is s**t

ziss_dm · Post by **ziss_dm** » Mon Oct 31, 2011 11:04 pm

Hi,

Can you make screenshots of GUI with copter 90 deg (both motor on/off)?
And also can you switch off in the sketch Baro, Mag, Camera stab, etc..

regards,
ziss_dm

copterrichie · Post by **copterrichie** » Mon Oct 31, 2011 11:08 pm

I forgot which ACC you are using, please share again.

Thanks

jevermeister · Post by **jevermeister** » Mon Oct 31, 2011 11:12 pm

Sorry, forgot that, I edited the first post:

it is a Bosch BMA020

@ziss: I will do that tomorrow night: the walking dead are waiting ;-)

Nils

copterrichie · Post by **copterrichie** » Mon Oct 31, 2011 11:28 pm

I know and understand you may not want to hear this but I have two of the BMA020, one is junk and the other I get some very weird readings from it.

jevermeister · Post by **jevermeister** » Mon Oct 31, 2011 11:35 pm

copterrichie wrote:I know and understand you may not want to hear this but I have two of the BMA020, one is junk and the other I get some very weird readings from it.

No probem richie, if it really is a bad sensor I will replace it ;-)

I just want a good copter.

Any tips for a better sensor? What about the standard nunchuck or the bma180? I just want something that fits on my Flydusense ;-)

Nils

copterrichie · Post by **copterrichie** » Mon Oct 31, 2011 11:48 pm

Well truthfully, I have only used the BMA020 and the MMA7455 which is not supported in the current versions of the WiiCopter Firmware. So I really don't have a suggestion. I have two ADSL335 that I need to test but have not done so yet.

P.S. From what I have read, the BMA020 is a good Accelerometer, I just believe there is a small batch that are not up to specification.

copterrichie · Post by **copterrichie** » Mon Oct 31, 2011 11:51 pm

P.S. Reading the Datasheet on the BMA020, there are some registers that should never be written to, it is very possible these registers are corrupted but I don't have the means to find this out.

Alexinparis · Post by **Alexinparis** » Tue Nov 01, 2011 7:51 pm

Hi,

Thank you very much for this input.
We can see clearly here how a wrong ACCZ could affect the resulting angles.
As you don't have a BMA180, it is useless to test it with trusted acc.
Activating this option should give for you the same result as 1.8p2.

jevermeister wrote:Hi Alex,

I did some testing today:

The setup is as follows:

Flyduino v2.1 Genuine WM+, BMA020, BMP085, HMC5883L, QuadX, SumPPM, HK SS18A ESC, eMax CF2822
I have my Copter stationary on the table and pressing it down while I power up the engines in acro mode/hover mode

1. Test: Multiwii 1.8p2 with imported Stability mode from MultiWii 1.7
2. Test: Multiwii 1.8p2 standard
3. Test: Multiwii Dev20111029 standard with trustedAccZ disabled
all PID etc are the same.

1. Test (old stab 1.7) A: Engines off

1. Test (old stab 1.7) B: Engines on

2. Test A: Engines off

2. Test B: Engines on

Remember: I am holding the copter flat on the table so absolutely NO real drift is happening.
I notice the decrease of AccZ while powering up - this is what you already mentioned and tried to fix in the current dev.
You can see that the copter thinks he is tilted to left front, so he would try to correct it by increasing throttle to that motor if he is in hover mode.
I also noticed, that the Mag is 90° off if I use the old stability mode. (I did no recalibration after uploading 1.8p2 standard)but that is corrected in 1.8.
While doing the test flights with 1.8p2 standard I noticed that the copter is drifting to right rear - so what I found here is absolutely expected!
flying with 1.7 stab mode is far better.
So why is AccZ doing this strange stuff???

3. Test A: Engines off

3. Test B: Engines on

As far as I can say it until now: I think the drift issue is fixed in the current dev...
I did some flight tests in my basement and the results look very promising, the drift seems to be eliminated and the copter behaves very smooth, it is way more flyable than 1.7.
I managed ot land on my desk and fly through my doors. COOL!

I hope these results help you in tracking down the issue for sure Alex!

Should I do the same test with the current dev and trusted AccZ on or is it unneccesary for you?

Nils

UndCon · Post by **UndCon** » Fri Nov 04, 2011 8:17 am

I have genuine WM+ and NK sensors and my copter drifts badly.
(my gimbal issue thread)

Stable mode is 100% useless as is and I tried a few versions and some dev version.

I cannot calibrate stable mode to be level. 1 motor is totally off and 1 is full on. the others drifts like crazy - and I can assure you that my floor is not moving.
No motors are engaged during tests
I even replaced sensors but no luck...

//UndCon

phebus · Post by **phebus** » Mon Nov 07, 2011 1:29 am

The decrease of AccZ while powering up the motors seems to be due to saturation of the BMA020 input. When motors are running, the maximum amplitude of high frequency motor vibrations may exceed the +/- 2G range of the BMA020 A to D converter because the 20 Hz low pass filter is after the A to D converter. When using an analog accelerometer, a low pass filter is located before the A to D converter to filter the unwanted high frequency accelerations and avoid saturation of the A to D converter input. On my tricopter i have been obliged to set the BMA020 input range to +/- 8G to get on the GUI, no variations of AccZ (255) with motors OFF then ON . Because the amplitude of vibrations depends of motor/propeller balancing, stiffness and damping of motor arms and is different on each multicopter, it may be convenient to select the accelerometer input range in the configurable parameters section of the Multiwii software.

mahowik · Post by **mahowik** » Mon Nov 07, 2011 4:49 am

Wow!!! Thanks a lot for the detailed explanation! This is the first time when we have a chance to really understand what is going on with Z acc axis. I will try the 4g/8g with my config. I hope it help to get Z more stable when engines is ON and reduce the acc drift.
Only one question: in this case why this issue is reproduced in most cases with the bma020 but not bma180? Are there (in bma180) some another internal variant of LPF connection?

ziss_dm · Post by **ziss_dm** » Mon Nov 07, 2011 7:23 am

Hi phebus,

Are you sure, that after changing range to 8G, the acc_1G is still 255? I think, it should be 63?

regards,
ziss_dm

zviratko · Post by **zviratko** » Mon Nov 07, 2011 1:13 pm

I solved problem in my case (YMMV) by changing to this init procedure (inspired by aeroquad).

Code: Select all

#if defined(BMA180)
void ACC_init () {
  delay(10);
  //default range 2G: 1G = 4096 unit.
  i2c_writeReg(BMA180_ADDRESS,0x0D,1<<4); // register: ctrl_reg0  -- value: set bit ee_w to 1 to enable writing
  delay(5);
  uint8_t control = i2c_readReg(BMA180_ADDRESS, 0x35);
  control = control | 0x3; // range to 3g!
  i2c_writeReg(BMA180_ADDRESS, 0x35, control);
  delay(5);
  control = i2c_readReg(BMA180_ADDRESS, 0x20);
  control = control & 0x7F; // zvi: edit, NOT TRUE ANYMORE! register: bw_tcs reg: bits 4-7 to set bw -- value: set low pass filter to 10Hz (bits value = 0000xxxx)
  control = control | 0x00; 
  i2c_writeReg(BMA180_ADDRESS, 0x20, control);
  delay(5); 
  control = i2c_readReg(BMA180_ADDRESS, 0x30);
  control = control & 0xFC; 
  control = control | 0x00;  // sets mode 0
  i2c_writeReg(BMA180_ADDRESS, 0x30, control); 
  delay(5); 
  acc_1G = 512;
}-

In this case, I keep using more sensitive and recommended mode 0, LPF is set to 1200Hz, range is set to 3g.

Works flawlessly for me(I still need to tune my PIDs, it's not aggressive enough - possibly because of range being 3g instead of 2g). acc_1g is STILL 512 (90 deg. tilted = 0, inverted = -512).

Could someone more knowledgeable doublecheck that it does what I claim it does? First time actually messing with code/registers like this...

Anyway, it is wrong to assume that all BMA180s are set the same way, some may come with different defaults, or someone messes with them and touches the EEPROM area (btw unlocking ee_w should not be necessary? Didn't try without it).

zviratko · Post by **zviratko** » Mon Nov 07, 2011 3:44 pm

found a bug, I'm setting
control = control | 0x3;

but it should be 0x6.

In fact the correct way to set 3g is

control = control & 0xF0;
control = control | 0x06;

so my way either sets 1.5g or 3g, depending on defaults... should set 3g if the defaults can be trusted. So does it make sense that acc_1g = 512?

mahowik · Post by **mahowik** » Mon Nov 07, 2011 4:03 pm

ziss_dm wrote:Are you sure, that after changing range to 8G, the acc_1G is still 255? I think, it should be 63?

In case of BMA020 I suppose 2 ways can be here:
1. change the acc_1g accordingly, i.e. 127 for 4g and 63 for 8g
2. reduce the delimiter in ACC_getADC(), i.e. 32 for 4g and 16 for 8g

zviratko · Post by **zviratko** » Mon Nov 07, 2011 5:03 pm

This time I got it right, sorry I never did bitmasking etc...
I found out I was lying about having Z = -512 when copter is upside down, the range was different, so I reverted to 2G setting (as it is obviously correct in this case), only left the filtering part and mode 0 setting...
Haven't tested flight yet, interesting that it worked beautifuly with the previous (b0rked) version...

Code: Select all

#if defined(BMA180)
void ACC_init () {
  delay(10);
  //default range 2G: 1G = 4096 unit.
  i2c_writeReg(BMA180_ADDRESS,0x0D,1<<4); // register: ctrl_reg0  -- value: set bit ee_w to 1 to enable writing
  delay(5);
  uint8_t control = i2c_readReg(BMA180_ADDRESS, 0x35);
  control = control & 0xF1; // masks offset_x and smp_skip bits
  control = control | 0x04; // sets range to 2g = 010
  i2c_writeReg(BMA180_ADDRESS, 0x35, control);
  delay(5);
  control = i2c_readReg(BMA180_ADDRESS, 0x20);
  control = control & 0x0F; //  masks tcs bits and sets bw to 0000b
  control = control | 0x70;  // sets bw to 0111b = 1200Hz
  i2c_writeReg(BMA180_ADDRESS, 0x20, control);
  delay(5); 
  control = i2c_readReg(BMA180_ADDRESS, 0x30);
  control = control & 0xFC;  // masks all but the last 2 bits
  control = control | 0x00;  // sets mode 0
  i2c_writeReg(BMA180_ADDRESS, 0x30, control); 
  delay(5); 
  acc_1G = 512;
}

zviratko · Post by **zviratko** » Mon Nov 07, 2011 8:48 pm

sorrry for spamming ;-)

FYI I have successfuly tested my version (patched into the MultiWii_dev_20111029 dev version) set to 2g. It flies beautifuly. No vibration, working TRUSTEDACCZ, working baro and mag, quite stable.
I switched to stock code (gonna try 1.9 next) and there is terrible noise on ACC, Z axis drops when motors are armed and it drifts terribly. I do not know what causes this behaviour, could someone with the drift problem confirm whether my version fixes it for them? I will investigate into the effect of the filters and different init scenarios...

btw if you test it, please reset arduino completely, looks like bma180 settings survive sketch upload (I thought it will reset, my bad - is there something like switched PIN#12 on Mega that resets on init?)

thanks

phebus · Post by **phebus** » Mon Nov 07, 2011 9:03 pm

Hi Ziss_dm

I have done the following modifications in the BMA020 section of the Multiwii software : control = control | (0x00 << 3); //Range 2G 00 replaced by control = control | (0x02 << 3); //Range 8G 00 and to get acc_1G = 255 in the GUI, ((rawADC[1]<<8) | rawADC[0])/64 , ((rawADC[3]<<8) | rawADC[2])/64 , ((rawADC[5]<<8) | rawADC[4])/64 ) replaced by ((rawADC[1]<<8) | rawADC[0])/16 , ((rawADC[3]<<8) | rawADC[2])/16 , ((rawADC[5]<<8) | rawADC[4])/16 ).

Regards,
Phebus

mahowik · Post by **mahowik** » Mon Nov 07, 2011 9:28 pm

Yes, it was clear

As I supposed (2nd way) above

Thanks in any case.
Alex

jevermeister · Post by **jevermeister** » Mon Nov 07, 2011 10:59 pm

Okay,
I just tested this fix of yours the same way I tested before:

This is the result:

1. Motors off, copter flat on table, Fix applied:

2. Motors on, full throttle flat on table, fix applied:

I am astonished, this might work.Z is not dropping a bit....

Does Alex know about this?

Nils

zviratko · Post by **zviratko** » Mon Nov 07, 2011 11:15 pm

I hope he follows this thread

However, my fix is behaving strange - it does what it does, but right know it looks like the stock code from 1.9 (with the previous fix) works way better. In fact, I got the best results from this:

Code: Select all

#if defined(BMA180)
void ACC_init () {
  delay(10);
  //default range 2G: 1G = 4096 unit.
  i2c_writeReg(BMA180_ADDRESS,0x0D,1<<4); // register: ctrl_reg0  -- value: set bit ee_w to 1 to enable writing
  delay(5);
  uint8_t control = i2c_readReg(BMA180_ADDRESS, 0x35);
  control = control & 0xF1; // masks offset_x and smp_skip bits
  control = control | 0x04; // sets range to 2g = 011
  i2c_writeReg(BMA180_ADDRESS, 0x35, control);
  delay(10);
  control = i2c_readReg(BMA180_ADDRESS, 0x20);
  control = control & 0x0F; // register: bw_tcs reg: bits 4-7 to set bw -- value: set low pass filter to 10Hz (bits value = 0000xxxx)
  control = control | 0x0F; // 10Hz filter again (0x70 for the previous 1200Hz filter)
  i2c_writeReg(BMA180_ADDRESS, 0x20, control);
  delay(10); 
  control = i2c_readReg(BMA180_ADDRESS, 0x30);
  control = control & 0xFC; 
  control = control | 0x00;  (mode 0 instead of mode 2)
  i2c_writeReg(BMA180_ADDRESS, 0x30, control);
  delay(10); 
  acc_1G = 512;
}

It switches back to 10Hz filter and mode 0. Almost a flat line when armed. With 1200Hz I get oscillations in all directions, even in mode 2. There's something VERY fishy going on in BMA180 whenever you mess with the settings. Some setting don't even get applied when just reinitialized from code (I upload a code with 3g setting and it still returned 2g values until i powercycled hard!). Some tests maybe flawed because the settings get mixed in this way - I got quite confused when testing...
I'll put in some code to soft-reset the BMA to be sure it behaves consistent...

jevermeister · Post by **jevermeister** » Mon Nov 07, 2011 11:57 pm

Really strange behavior you are describing there.

I have not tested it in flight yet.

But the effect only occurs if I have the gopro onbaord, because the copter is heavier I have to set higher throttle and this influences accZ a lot. Anyway: no drift in the basement without camera...

Sa we have to wait until I make a FPV flight outside.
I have to give TKD lessons tomorrw, so there is no time. Wednesday is the if the weather is ok.

Nils

ziss_dm · Post by **ziss_dm** » Tue Nov 08, 2011 5:34 am

phebus wrote:Hi Ziss_dm

I have done the following modifications in the BMA020 section of the Multiwii software : control = control | (0x00 << 3); //Range 2G 00 replaced by control = control | (0x02 << 3); //Range 8G 00 and to get acc_1G = 255 in the GUI, ((rawADC[1]<<8) | rawADC[0])/64 , ((rawADC[3]<<8) | rawADC[2])/64 , ((rawADC[5]<<8) | rawADC[4])/64 ) replaced by ((rawADC[1]<<8) | rawADC[0])/16 , ((rawADC[3]<<8) | rawADC[2])/16 , ((rawADC[5]<<8) | rawADC[4])/16 ).

Regards,
Phebus

Hi,
The BMA020 has only 10 bit resolution..
http://www.sensorica.ru/pdf/BMA020.pdf

/64 needed to remove "new_data" and "unused" bits.

regards
ziss_dm

zviratko · Post by **zviratko** » Tue Nov 08, 2011 6:45 am

jevermeister wrote:But the effect only occurs if I have the gopro onbaord, because the copter is heavier I have to set higher throttle and this influences accZ a lot. Anyway: no drift in the basement without camera...

The LPF setting is more or less a guesswork - MW init didn't work for me so I went to aeroquad and used their setting. The resonance frequency of various thing onboard may cause different LPF settings to filter this out (and when you move stuff around you find out it doesn't work anymore with the previous setting). So add a gopro which resonates differently and voila, it vibrates.
Maybe changing resolution will work, setting it to 8g and rescaling everything.... basically, that's what my original (b0rked) patch did - it set 3g instead of 2g and that in combination with the LPF guesswork did the trick, but it's just a trick...

ziss_dm · Post by **ziss_dm** » Tue Nov 08, 2011 6:56 am

Hi zviratko,

Theoretically, for IMU complimentary filter you need high bandwidth from gyro and low bandwith from ACC. Assuming your control loop is running 400Hz, you need LPF for gyro 200Hz and lowest possible setting for ACC. Not sure, why you trying to increase bandwith for ACC.

regards,
ziss_dm

zviratko · Post by **zviratko** » Tue Nov 08, 2011 8:00 am

I don't know how/if any/ filtering is implemented in MW code, BMA180 doesn't return absolute measure values but also filters it out, and the sheet says you can poll it for fresh values very fast. As I said - it was just guesswork. If 10Hz filter worked for me, I wouldn't have bothered. But it didn't work for me so I modified it. If 10Hz is all you need then why is this thread here? ;-)

jevermeister · Post by **jevermeister** » Tue Nov 08, 2011 8:05 am

Hmm,
damn, I thought we had the solution...

But we should not forget the most important fact: Phebus said, that it is a vibration issue.

I had my first BMA020 fixed with sticky foam like the gyro but on my new copter I use the flydusense 2 and the BMA020 is fixed with pinheaders.
I did not have the drifting with my old copter but now I have it.
So Phebus might be very very right.
So in my opinion, the best solution would be a proper vibration dampening of the acc like I had on nDROiiD 1 and on my shrediquette tricopter..

What do you think?

zviratko · Post by **zviratko** » Tue Nov 08, 2011 8:17 am

I have no gyro vibration, I only have ACC vibration. Are gyros vibrating on you or is it acc?
I have much more vibration when sensorstick is not fixed to the frame - if I fix it in foam like you did it gets very very bad, when I fix it firm on the frame the vibrations go away... mostly.

Yes, the errors we are seeing are vibrations, but the presumption "it will not vibrate" is unreal. Also, some of us had vibration and drift, some had much less vibration but a drop on Z axis (this still dazzles me), some of us just fly

Someone with a degree in mechanical engineering should step in right now...

jevermeister · Post by **jevermeister** » Tue Nov 08, 2011 11:34 am

Ok,
I did some thinking and in my opinion vibrations are more of a problem for an ACC sensor. A gyro should not recognize them as long as they are not angular. But a vibration is a wave of accelerations mostly linear. So my vibrations are ruining the sensor read.

This is just my theory and that stands in contradiction to the common meaning - I know.

Someone should test the following to be sure, that the readings of accZ are caused by vibrations.

1. decouple the sensor completely from the frame by using looong cables and start up the engines.
- If he still does the accZ behaviour: We have a electrical problem or a code problem for sure
- if there is no weird behaviour it might be the vibrations but we should do a second test:

2. Sensor on the frame but the power is coming from a different source, just be sure to connect - to have a common ground.
- if accZ behaves crazy: Vibrations
- if not: electrical problems

is someone willing to test this!?

Nils

timecop · Post by **timecop** » Tue Nov 08, 2011 11:54 am

This only affects BMA020, right? I did TRUSTED_ACCZ on my hardware with adxl345 as I was curious if AccZ would change ... and it was fine even at max throttle.

phebus · Post by **phebus** » Tue Nov 08, 2011 2:53 pm

dongs wrote:This only affects BMA020, right? I did TRUSTED_ACCZ on my hardware with adxl345 as I was curious if AccZ would change ... and it was fine even at max throttle.

Hi dongs

The ADXL345 works fine because in the Multiwii software the acceleration range is set to +/- 8G (register 0x31, 0x0B) and thus there is no saturation of the A to D converter with high frequency motor vibrations. Also the sensitivity is maintained to 256 LSB/g because Full_RES bit is set to 1 and the accelerometer is in 12 bit mode. The bandwith is set to 100 Hz (register 0x2c, 0x0b) and could be reduced to get a cleaner acceleration signal. The ADXL345 accelerometer is better than the BMA020 because the acceleration range can be increased up to +/-16G while the sensitivity is maintained to 256 LSB/g whereas with the BMA020 the sensitivity at +/-8G is lowered to 64 LSB/g.

Regards,
Phebus

zviratko · Post by **zviratko** » Tue Nov 08, 2011 3:13 pm

phebus wrote:
dongs wrote:This only affects BMA020, right? I did TRUSTED_ACCZ on my hardware with adxl345 as I was curious if AccZ would change ... and it was fine even at max throttle.

Hi dongs

The ADXL345 works fine because in the Multiwii software the acceleration range is set to +/- 8G (register 0x31, 0x0B) and thus there is no saturation of the A to D converter with high frequency motor vibrations. Also the sensitivity is maintained to 256 LSB/g because Full_RES bit is set to 1 and the accelerometer is in 12 bit mode. The bandwith is set to 100 Hz (register 0x2c, 0x0b) and could be reduced to get a cleaner acceleration signal. The ADXL345 accelerometer is better than the BMA020 because the acceleration range can be increased up to +/-16G while the sensitivity is maintained to 256 LSB/g whereas with the BMA020 the sensitivity at +/-8G is lowered to 64 LSB/g.

Regards,
Phebus

BMA180 has 512LSB/g at 16g setting - so why is it set to 2g? Is saturation a problem? I think only gyro is used when acceleration > 1.4g anyway... so the problem is just noise.
Would it be worthwile to set it to 12bit as well? It could "filter" (ehm, ehm..) the noise as well...

mahowik · Post by **mahowik** » Tue Nov 08, 2011 4:55 pm

phebus wrote:The ADXL345 works fine because in the Multiwii software the acceleration range is set to +/- 8G (register 0x31, 0x0B) and thus there is no saturation of the A to D converter with high frequency motor vibrations. Also the sensitivity is maintained to 256 LSB/g because Full_RES bit is set to 1 and the accelerometer is in 12 bit mode. The bandwith is set to 100 Hz (register 0x2c, 0x0b) and could be reduced to get a cleaner acceleration signal. The ADXL345 accelerometer is better than the BMA020 because the acceleration range can be increased up to +/-16G while the sensitivity is maintained to 256 LSB/g whereas with the BMA020 the sensitivity at +/-8G is lowered to 64 LSB/g.

Hi phebus,

Thanks for the clear posts.
In case of bma020 we can try to increase the acceleration range step by step. I.e. if it has the acc Z issue, but config/copter has the "middle" vibrations, it make sense to set to +/-4g and see the results on full throttle. And if Z is not changed keep the 4g, otherwise go to the 8g.
So it can helps to keep at least 128 LSB/g... no so good but better and i suppose it will be enough to get it stable.

thx-
Alex

mahowik · Post by **mahowik** » Tue Nov 08, 2011 5:24 pm

Also I'm going to play with Nunchak. As it has analogue acc chip it possible to add the condensers with more capacity to filter unnecessary high frequency (vibrations).

mahowik · Post by **mahowik** » Wed Nov 09, 2011 8:46 pm

Hi guys,

Good news!
I have tried this fix (talking about increasing of acceleration range for bma020) yesterday and it work perfect, very stable with real ACC Z data (i.e. when TRUSTED_ACCZ uncommented).

As I have very noisy/vibrated config I have set the following changes:
1. Set the acceleration range to +/-8g
2. Set acc_1G to 127, and data delimiter to 32

Code: Select all

#if defined(BMA020)
void ACC_init(){
  i2c_writeReg(0x70,0x15,0x80);
  uint8_t control = i2c_readReg(0x70, 0x14);
  control = control & 0xE0;
  control = control | (0x02 << 3); //Range 8G 10
  control = control | 0x00;        //Bandwidth 25 Hz 000
  i2c_writeReg(0x70,0x14,control); 
  acc_1G = 127;
}

void ACC_getADC(){
  TWBR = ((16000000L / 400000L) - 16) / 2;
  i2c_getSixRawADC(0x70,0x02);
  ACC_ORIENTATION(    ((rawADC[1]<<8) | rawADC[0])/32 ,
                      ((rawADC[3]<<8) | rawADC[2])/32 ,
                      ((rawADC[5]<<8) | rawADC[4])/32 );
  ACC_Common();
}
#endif

3. increase the factor of acc LPF to 64 (>>6) in IMU

Code: Select all

      accTemp[axis] = (accTemp[axis] - (accTemp[axis] >>6)) + accADC[axis];
      accSmooth[axis] = accTemp[axis]>>6;

4. increase the GYR_CMPF_FACTOR to 350.0f

Code: Select all

#define GYR_CMPF_FACTOR 350.0f

5. uncomment/turn on MG_LPF_FACTOR to reduce the MAG noise

Code: Select all

#define MG_LPF_FACTOR 4

6. set the gyro LPF to 42Hz

Code: Select all

#define ITG3200_LPF_42HZ

It was tested on MultiWii_dev_20111029 for acro, stable and MAG modes... all modes works fine!

Thanks a lot to all for your helps!

Alex

phebus · Post by **phebus** » Fri Nov 11, 2011 12:59 am

In order to confirm that high frequency motor vibrations saturate the BMA020 A to D converter when G range is set to +/- 2G, i have glued on the central plate of my tricopter a +/- 3G ADXL335 analog accelerometer with its first order low pass filter set to 500 Hz. With motors running at min. throttle (1300) I have taken a picture of the ADXL335 accelerometer vertical ouput displayed on my oscilloscope. The settings are : Y= 200 mV/division = 0.6 G/division, X=2mS/division.

Tricopter Acc Z, 1 div Y=0.6G, 1 div X=2mSa.jpg

On the picture we can see high frequency vibrations at approximately 840 Hz with a maximum amplitude of +/- 2.2 G. This maximum amplitude needs to be corrected for the attenuation of the 500Hz low pass filter. For a first order low pass filter, the amplitude is divided by half (6db) every time the frequency double. The corrected maximum amplitude is +/- 2.2 G x 1.68= +/- 3.7G which gives taking into account the gravity, a maximum acceleration at the input of the accelerometer of + 4.7 g, - 2.7 G. This explain why the 4 G range was not enough and that i had to switch to the 8 G range. These high frequency vibrations are coming from the switching of motor poles. On a 14 poles motor, the magnets are rotating 7 times slower than the field which gives a rotating speed of (840/7)x60= 7200 rpm. On the picture we can also see a low frequency of approximately 120 Hz (7200 rpm) due to propeller unbalance. The picture shows also that the main part of the vibrations comes from motor poles switching. As a conclusion, when using a digital accelerometer, we must verify that the maximum amplitude of high frequency vibrations does not exceed the accelerometer A to D converter input range because the low pass filter used to filter the high frequency vibrations is after the A to D converter.

phebus · Post by **phebus** » Fri Nov 11, 2011 1:03 am

Under is the picture missing.

Tricopter Acc Z, 1 div Y=0.6G, 1 div X=2mSa.jpg

ziss_dm · Post by **ziss_dm** » Fri Nov 11, 2011 6:54 am

Hi phebus,

Fist of all, this was great idea to make test like that!!

And defenetly, if you have 4.7g vibration at 850Hz sensor would saturate.
But I would disagree with your conclusions.

1) You forget that brushless motors, usually perform 6 commutations per electrical rotation. ;( So, 14 pole motor, rotating at 7200 rpm commutating at speed: 7200/60*7*6=5,040 Hz. Which shuld be easilly filtered by BMA's analogue filter.
2) All handheld electrical tools are rated not to exceed 2.5 g peak vibration and they vibrating much harder than my copter

If I were you, I would try the following.
1) checked for electrical/magnetic noise
2) checked for resonances
3) repeated test with only one motor.

BTW: Changing range to 8g would be simple solution, but with 10bit ADC it would reduce angular resolution appriximatelly to 1 deg. (With 2g range, for BMA020 we have 0.2 deg resolution)

regards,
ziss_dm

zviratko · Post by **zviratko** » Fri Nov 11, 2011 7:34 am

You are forgetting the fact that most people will not have a vibration-free copter, most people do not have a mechanical engineering degree, and - most importantly - most people will expect the code and settings to "just work". So if 8G range is fine for 99% of people to make it float nicely in air and not drop like a stone, then make it the default and let the 1% reduce it if they want to hack it into perfection... better than having clueless users wonder why it's drifting and behaving strangely...

phebus · Post by **phebus** » Sat Nov 12, 2011 1:23 am

Hi ziss_dm

When I have done my tests, I have recorded the vertical acceleration with only one motor on at iddle.
The settings are : Y= 200 mV/division = 0.6 G/division, X=2mS/division.

Tricopter, one motor on.jpg

On this picture of my oscilloscope, the switching of motor poles is at 750 Hz corresponding to a rotating speed of (750/7)60= 6400 rpm. There is no higher frequency than the 3 phase rotating field at 750 Hz = 750x60=45,000 rpm (http://www.aerodesign.de/peter/2001/LRK350/Warum_dreht_er_so_eng.html. This frequency is easily filtered by the digital filter of the BMA020 set at 20Hz. The maximum vertical acceleration is equal to +/- 1.6 G. After correction for the attenuation of the accelerometer 500Hz first order low pass filter at 750 Hz we get +/- 1.6 G x 1.7 = +/- 2.4 G.
I have also recorded the vertical acceleration with all motors off with the same settings as above.

Tricopter , all motors off.jpg

This picture does not show any electrical/magnetic noise.

regards,
Phebus

ziss_dm · Post by **ziss_dm** » Sun Nov 13, 2011 12:09 pm

Hi Phebus,

Can you also make another test, the motor is running but sensor not touching central plate, jut to make sure, that what you see is acceleration, but not electromagnetic interference from ESC's.

On this picture of my oscilloscope, the switching of motor poles is at 750 Hz corresponding to a rotating speed of (750/7)60= 6400 rpm. There is no higher frequency than the 3 phase rotating field at 750 Hz = 750x60=45,000 rpm

Not sure, I understand your point. If you have sinusoidal control, torque always constant and there no torque ripple. If you have stepper control, there are 6 discrete commutations per electrical rotation. During each commutation motor experience the small torque ripple.

http://bldc.wikidot.com/bldc-and-8051
http://bldc.wikidot.com/p-esc-motor
http://www.google.com.au/search?gcx=c&s ... que+ripple

regards,
ziss_dm

jevermeister · Post by **jevermeister** » Sun Nov 13, 2011 12:40 pm

ziss_dm wrote:Hi Phebus,

Can you also make another test, the motor is running but sensor not touching central plate, jut to make sure, that what you see is acceleration, but not electromagnetic interference from ESC's.

On this picture of my oscilloscope, the switching of motor poles is at 750 Hz corresponding to a rotating speed of (750/7)60= 6400 rpm. There is no higher frequency than the 3 phase rotating field at 750 Hz = 750x60=45,000 rpm

Not sure, I understand your point. If you have sinusoidal control, torque always constant and there no torque ripple. If you have stepper control, there are 6 discrete commutations per electrical rotation. During each commutation motor experience the small torque ripple.

http://bldc.wikidot.com/bldc-and-8051
http://bldc.wikidot.com/p-esc-motor
http://www.google.com.au/search?gcx=c&s ... que+ripple

regards,
ziss_dm

that was, what I tried to hint out at the beginning, we need different test setups.

Nils

ziss_dm · Post by **ziss_dm** » Fri Nov 18, 2011 4:21 am

Hi Phebus,

Any news?

regards,
ziss_dm

phebus · Post by **phebus** » Thu Nov 24, 2011 12:11 am

Hi Ziss_dm,

I have checked, with motors running and test accelerometer not touching the central plate, that the accelerometer output is flat showing that there is no electromagnetic interference from ESC’s. This is confirmed by the HMC5883L digital compass heading output not moving at all with motors running or not.
I have done more tests with one motor to have a better understanding of the origin of the high frequency vibrations generated by the torque ripple of the brushless motor. For this, I have added a photodiode to measure motor rpm versus torque ripple frequency because I could not see a physical explanation for the ratio of approximately 7 between the torque ripple frequency and the motor rotational frequency except that for the 14 poles motor used, the magnets are rotating 7 times slower than the magnetic field.
The more accurate measurement with the photodiode shows that the torque ripple frequency (750Hz) is around 12 times the motor rotational frequency (65Hz = 3900 rpm at iddle) and not 7 as measured first. On a brushless motor there are two dominant sources of torque ripple: cogging and energized torque ripple as described in chapter 5 of “Electronic control of torque ripple in brushless motors” by Peter Franz Kocybick, http://lib-srvr9.lib.plymouth.ac.uk:8080/handle/10026.1/727 .

1-Cogging:

The presence of stator slots to hold the armature windings is the cause for cogging. The magnetic path reluctance changes when a magnet moves from covering a stator tooth (lower reluctance path) to covering the slot opening (higher reluctance path). The magnets will therefore always try to align with the stator teeth to minimize reluctance. When the shaft of a brushless motor is turned by hand in the unenergized condition, the rotor positions where the magnets align with the stator teeth can be felt. As the reluctance changes occur whenever a magnet edge aligns with a stator tooth, the cogging frequency is the number of slots (12)times the rotational frequency (65Hz) which is what has been measured on the test setup. The amplitude of the cogging torque can be considered constant and independent of rotational frequency and armature current and it entirely depends of motor geometry.

2-Energized torque ripple:

Energized torque ripple is produced through the interaction of magnet flux from the magnets and the magneto-motive force (MMF) setup by the phase currents. Torque ripple frequencies are multiples of 6 times the field frequency.
The field frequency being equal to 7 times the rotational frequency we get an energized torque ripple frequency of 65x7x6=2730Hz. This frequency cannot be seen on the recordings with the ADXL335 accelerometer Z axis because of its limited 500 Hz bandwidth. To see it I have used the y axis of the ADXL335 accelerometer with 1600Hz bandwidth and I measured around 2500Hz.

Conclusion:

The energized torque ripple is at a frequency higher than the bandwidth of the accelerometers used on Multicopters and it should be filtered by the anti-aliasing filter of around 1500Hz on the input of the accelerometer A to D converter. The cogging frequency, which is lower, will not be filtered by the anti-aliasing filter and the accelerometer range should be chosen to avoid the saturation of the A to D converter input. For the BMA020 accelerometer set to +/- 2G, after the zero of the gravity the maximum input before saturation is + 1G and -3G which can be easily exceeded by the maximum acceleration ripple of the brushless motors. Because the maximum amplitude of the acceleration ripple is different on each multicopter, it may be convenient to select the accelerometer input range in the configurable parameters section of the Multiwii software.

Regards,

Phebus

ziss_dm · Post by **ziss_dm** » Thu Nov 24, 2011 5:39 am

Hi Phebus,

The Cogging torque ripple defenetly can explain presence ov vibrations with req. 12 times of rotation frequency but cannot explain the accelerations you getting. ;(
1) Cogging torque ripple is pretty much unnoticable with low KV outrunners, we using. http://www.rcgroups.com/forums/showthread.php?t=1006721
2) Assuming we are talking about only forced vibrations (resonances is better to fix by frame design), amount of energy needed to vibrate 100g mass with frequency 750Hz with acceleration 2g is around 153W!!!!

BTW: With adxl345 set to bandwith 1200 and range +-2g, I'm hardly getting 0.2g vibration at idle (Motors: DT750). (I will double check and post results.)

BTW2: Can you also describe your setup? How you getting 3900 rpm at idle, or you mean hover?

regards,
ziss_dm