export vibrations log as csv from multiwiiconf ?

[natael]

Hi,

The only sort of related answers to this topic question i could found were at viewtopic.php?f=8&t=4348&p=44553&hilit=csv#p44553
and with the EZ-GUI app.
I was hoping there'd be a simpler solution, already implemented in the multiwiiconf GUI, to export the data seen in the graphs of the multiwiiConf, and concerning specifically the vibrations as felt by the gyros and Acc, and if possible, before any post-processing such as the default lowpass (256 Hz if i understand the config.h correctly).
And if it is indeed implemented, what are the units used by both the values for gyros and Acc ?

Is there a kind soul to advise on that ?

Could be .csv , .txt, or whatever , as long as i can import it elsewhere (Matlab, ...)

Thanks

[natael]

Hi,

Since i had no luck with this question, i've started coding my own vibration logger that interfaces with Matlab for real time measurements.
ITG3205 was easy, lots of tutorials.
However, for the BMA180, i had better luck reading through the multiwii code, to get the part that exported the accADC values.
The BMA180 datasheet is not as clear as the ITG one. Can anyone tell me if i get that correctly :

In this :

Code: Select all

control = i2c_readReg(BMA180_ADDRESS, 0x35);
  control = control & 0xF1;        // save offset_x and smp_skip register
  control = control | (0x05 << 1); // set range to 8G
  i2c_writeReg(BMA180_ADDRESS, 0x35, control);

The datasheet says that at a range of 8G, the ADC resolution is 0.99 mg/LSB, which i'll round to 1mg/LSB for my question below.

Does this mean that the subsequent accADC values that get read from the data register (0x02 and up) are output directly in mg ?
So, when i print out a value, say, accADC[2] = 225, i should understand 225 mg ? Is that correct ? Or is there another calculation to get to this unit ?
I'm not talking about the calibration here, but just the conversion of the value to the physical unit in mg.

Thank you

[timecop]

acc (and gyro) values are usually divided by 4 or 8 for some idiotic reason in multiwii.
you better check that the driver doesn't d o something like >> 4 or >> 2 in getADC() function.

[natael]

acc (and gyro) values are usually divided by 4 or 8 for some idiotic reason in multiwii.
you better check that the driver doesn't d o something like >> 4 or >> 2 in getADC() function.

Thank you for replying timecop.

I had a look again. Indeed, it seems to be not only divided by 4, but there's also truncation, which confuses me. Here is the code :

Code: Select all

void ACC_getADC () {
  i2c_getSixRawADC(BMA180_ADDRESS,0x02);
  //usefull info is on the 14 bits  [2-15] bits  /4 => [0-13] bits  /4 => 12 bit resolution
  ACC_ORIENTATION( ((rawADC[1]<<8) | rawADC[0])>>4 ,
                   ((rawADC[3]<<8) | rawADC[2])>>4 ,
                   ((rawADC[5]<<8) | rawADC[4])>>4 );

I don't understand why this is necessary. The useful data in the 0x02 register starts at the 3rd bit, and span from the 2nd to the 15th bit. That's 14 bits, and as said in the comment. RawADC values are put in 16 bits integers in the end anyway without any other computation, in

Code: Select all

int16_t  accADC

using :

Code: Select all

#define ACC_ORIENTATION(X, Y, Z)  {accADC[ROLL]  = -X; accADC[PITCH]  = -Y; accADC[YAW]  = Z;} 

So, that cannot be to save memory, can it ?
Then why throwing 2 bits away ? Is it to comply with some later computation in the stabilisation part that needs such truncation ? Or is it for cleaning the data from some random noise that is as high as what the 2 discarded bits can go (3 ?...) ?

Besides, for the gyros, there is no such truncation. Full resolution of 14 bits is preserved , as they only shift the bytes by >>2 bits :

Code: Select all

void Gyro_getADC () {
  i2c_getSixRawADC(ITG3200_ADDRESS,0X1D);
  GYRO_ORIENTATION( ((rawADC[0]<<8) | rawADC[1])>>2 , // range: +/- 8192; +/- 2000 deg/sec
                    ((rawADC[2]<<8) | rawADC[3])>>2 ,
                    ((rawADC[4]<<8) | rawADC[5])>>2 ); 

Anyway, i guess that kinda answers it : I have to multiply the output rawADC value by 4 to retrieve the original physical unit in mg
did i get all this right ?

Thanks for your help.

[Alexinparis]

Or is it for cleaning the data from some random noise that is as high as what the 2 discarded bits can go (3 ?...) ?

This is one of the reason: useless info on last bits due to noise.

Is it to comply with some later computation in the stabilisation part that needs such truncation

yes also, it avoids in some case (int32_t) cast in further computations.

Besides, for the gyros, there is no such truncation. Full resolution of 14 bits is preserved , as they only shift the bytes by >>2 bits :

This is the same reason for gyro: full resolution is 16 bit long and we skip the last bits.

Anyway, i guess that kinda answers it : I have to multiply the output rawADC value by 4 to retrieve the original physical unit in mg
did i get all this right ?

it depends on your ACC type, but in this case, yes.

[natael]

Alex, merci beaucoup for taking the time for this detailed answer.
This little thread helped me finish a Matlab/arduino/multiwii data logger for my vibrations test bench.
I'll send a few samples here after i've done a couple tests on different motor brands, which will ultimately go on a comrade's website and be updated from time to time.

[natael]

After a few measurements and a deeper look in the Sensors sketch, I am puzzled with the differences of low-pass between MPU6050-ACC and BMA180, could someone help me understand ?

Default Low-pass for MPU6050, ACC is 260 Hz.

i2c_writeReg(MPU6050_ADDRESS, 0x1A, MPU6050_DLPF_CFG); //CONFIG -- EXT_SYNC_SET 0 (disable input pin for data sync) ; default DLPF_CFG = 0 => ACC bandwidth = 260Hz GYRO bandwidth = 256Hz)

And default Low-Pass for BMA180 is 10 Hz :

control = control | (0x00 << 4); // set low pass filter to 10Hz (bits value = 0000xxxx)
i2c_writeReg(BMA180_ADDRESS, 0x20, control);

Why such an enormous difference between both sensors ? Is it because BMA180 is "crappier" than the ACC of the MPU6050 ?
If not, how does this affect flight behavior and PIDs ? What would happen if I set the BMA180 at a higher bandpass ? Say, the same as MPU6050-acc ?

Or is it because the MPU6050 doesn't have separate settings for the gyro and ACC, forcing the ACC to simply be constrained by what the gyro needs ?

Thank you