hoshinmk112 / ardu-imu

Automatically exported from code.google.com/p/ardu-imu
0 stars 0 forks source link

Documentation, ground start and other code queries #31

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
ArduIMU_1.9.8 target device code

Having experimented with an ArduIMU running 1.9.8 code, we found that, unless 
we do a ground start with the sensor perfectly flat in the XY-plane, large 
offsets are applied during subsequent operation.  Looking at the code, it's 
clear that ground start does a simple offset process, assuming a perfectly flat 
sensor.  I have not found any mention of this ground start requirement in the 
Wiki.

During this ground start, an 'average' procedure is performed on 400 samples, 
using the code snippet in Arduimo.ino:

for (int i=0;i<400;i++) // We take 400 readings...
{
    Read_adc_raw();     // returns AN[]
    for (int y=0; y<=5; y++) // Read initial ADC values for offset
        AN_OFFSET[y] = AN_OFFSET[y]*0.8 + AN[y]*0.2;
...

I'm not sure quite what was intended by this, but it will not perform a simple, 
linear average (which would be my choice for a simple startup offset 
compensation calbration).  The gain of this process tends to unity for large n, 
but never reaches it (for n=4, the gain is 0.8976).  Since each sample is 
effectively scaled by 0.8 each time a new sample is taken, each i'th sample 
ends up with a gain of 0.2*0.8^(n-i-1), where n is the sample limit, i.e. 
there's an exponential bias towards to most recent samples.  Apart from sample 
zero, which has a gain of 0.8^n

Whilst an interrupt is set up to allow the MPU-6000 to interrupt the Atmel 
processor when a data sample is ready, and this interrupt triggers the function 
void MPU6000_data_int() in MPU6000.pde, the main processing loop does not use 
it, instead using a 20 millisecond loop timer.  Thus, the sample generation and 
consumption are asynchronous (or plesiochronous), and there will be times when 
a sample read hits the point at which the new sample is being updated by the 
sensor (a sync slip), giving incoherent samples, and maybe even incoherent 
upper/lower bytes values.

The accelerometer scaling configuration is confusing.  The code in MPU6000.pde 
is as follows:

MPU6000_SPI_write(MPUREG_ACCEL_CONFIG,0x08); // Accel scale 4g (4096LSB/g)

The constant 0x08 corresponds to an FSD of +/-4g according to the sensor 
datasheet, but this also means a scaling of 8192LSB/g.  Experiment shows the 
sensor returning values around 4096 when static, suggesting that there is an 
inconsistency somewhere in the code, or in the data sheet.

Since we do not know the design intent or design requirements for this code, 
it's hard for us to say what is right or wrong; maybe someone more familiar 
with the ArduIMU design and implementation could comment on these issues.  
Thanks.

Original issue reported on code.google.com by cola...@paranoiaproducts.co.uk on 6 Feb 2013 at 6:29

GoogleCodeExporter commented 9 years ago
You are right about the Accel_config inconsistency.
The value is directly connected to the gravity value in the arduimu.ino file.
Each AFS_SEL value has it's own gravity value.
The Gravity value specified in the Arduimu.ino (4096) works fine with AFS_SEL = 
3 (+- 16g)
To do this you are supposed to modify the MPU6000 line in:
MPU6000_SPI_write(MPUREG_ACCEL_CONFIG,0x18);
and the gravity value can remain:
#define GRAVITY 4096
I tried to set the accelerometers to 4 and 8 g with the relative gravity 
factors, but the centrifugal correction didn't seem to work properly.
Regards Marco

Original comment by marco.di...@gmail.com on 27 Mar 2013 at 10:31