ArduIMU V3 all axes output wrong values!

I cannot believe that I'm the only one who noticed that!  I would write it off as a faulty device but I've got two brand new once here that produce identical output with the same unmodified firmware (V1.9)

Here is the description of the problem:

1. Initialize IMU level
2. Slowly turn 90 in roll
3. Return to horizontal orientation.
4. Slowly turn -90 in roll
5. Return to horizontal orientation.
6. Repeat for pitch and yaw (yaw rotate 360 in 90 deg increments)

Each axis output should correspond to the number of degrees turned.  Instead I get the following:

Roll reading: actual roll: - 90 deg -> RLL output: - 120
                          +  90 deg -> RLL output: + 120
Pitch reading: actual pitch: -90 deg -> PCH output: -50 (goes from 0 to -89 and then decreases to -50)
                             +90 deg -> PCH output: +50 (goes from 0 to 89 and then decreases to 50)
Yaw reading: actual yaw:  0 deg -> YAW output: 180
                          90 deg -> YAW output: 108
                          180 deg -> YAW output: 45
                          270 deg -> YAW output: -40
                          360 deg -> YAW output: -180

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –


  • I am not sure about the unit you are speaking . Gyro provides three values : roll, pitch and yaw each in degrees. Shift the body by a known angle(eg 90 degrees) and identify change in angle (eg yaw). The actual chnage should be 90. The difference is the error. If u r performing experiment to obtain some other information out of gyros( other then angular change in roll,pitch, yaw) then i am unaware to that



  • Keep the object stationary and observe the readings. This will help u to determine error introduced in each set of observation. subtract the error to obtain true values.
  • the tan,sin,cos are multiplied by 1.9--- delete this 1.9 so in the last part in DCM
    void Euler_angles(void)
    #if (OUTPUTMODE==2) // Only accelerometer info (debugging purposes)
    roll = atan2(Accel_Vector[1],Accel_Vector[2]); // atan2(acc_y,acc_z)
    pitch = asin((Accel_Vector[0])/(double)GRAVITY); // asin(acc_x)
    yaw = 0;
    pitch = asin(DCM_Matrix[2][0]);
    roll = atan2(DCM_Matrix[2][1],DCM_Matrix[2][2]);
    yaw = atan2(DCM_Matrix[1][0],DCM_Matrix[0][0]);

  • Hey,
    I am not using DCM algo for arduIMU v3 cause it is not giving me correct anglular orientation.
    I have used only MPU6000 for orientation calculation.
    The function for used for calculation gyro angle is as below:

    void Get_Gyro_Rates(unsigned long dt)
      byte_H = MPU6000_SPI_read(MPUREG_GYRO_XOUT_H);
      byte_L = MPU6000_SPI_read(MPUREG_GYRO_XOUT_L);
      gyroXRaw = ((byte_H<<8)| byte_L) - GYRO_XOUT_OFFSET;
      // Read GyroY
      byte_H = MPU6000_SPI_read(MPUREG_GYRO_YOUT_H);
      byte_L = MPU6000_SPI_read(MPUREG_GYRO_YOUT_L);
      gyroYRaw = ((byte_H<<8)| byte_L) - GYRO_YOUT_OFFSET;
      // Read GyroZ
      byte_H = MPU6000_SPI_read(MPUREG_GYRO_ZOUT_H);
      byte_L = MPU6000_SPI_read(MPUREG_GYRO_ZOUT_L);
      gyroZRaw = ((byte_H<<8)| byte_L) - GYRO_ZOUT_OFFSET;
      gyroXRate = (float)gyroXRaw/gyro_xsensitivity*dt*0.001;
      gyroYRate = (float)gyroYRaw/gyro_ysensitivity*dt*0.001;
      gyroZRate = (float)gyroZRaw/gyro_zsensitivity*dt*0.001;
        GYRO_XANGLE += gyroXRate;
        GYRO_YANGLE += gyroYRate;
    //  if(abs(gyroZRaw)>1)  
        GYRO_ZANGLE += gyroZRate;
      Serial.print(" ");

    here, I am am continuously getting increments or decrements in each angle..
    If you can help please suggest me the best way to use arduIMU v3..?

  • Artem,

         I just wanted to confirm that the two simple changes (GRAVITY=8192 and the two gain changes) are all that is required for you an ArduIMU 1.9.8 (neglecting YAW improvements - I don't use a GPS). I will retest my measurements - do you go all the way near 90 deg or just to maybe 45 deg.

        Do you have any expectations of whether it will drift much as long as the rotation rates are low?

         I appreciate your expertise in this - don't you think that whoever is responsible for the code should make your changes and release it.

  • It is Nov 20, 2012 and I am testing a V3 board. I added Artem's two fixes in the ArduIMU.pde :


    #if BOARD_VERSION == 3
    #define SERIAL_MUX_PIN 7
    #define RED_LED_PIN 5
    #define BLUE_LED_PIN 6
    #define YELLOW_LED_PIN 5   // Yellow led is not used on ArduIMU v3
    // MPU6000 4g range => g = 4096
    #define GRAVITY 8192



    // WAS  #define Kp_ROLLPITCH 0.015
    // WAS  #define Ki_ROLLPITCH 0.000010
    #define Kp_ROLLPITCH 1.515/GRAVITY
    #define Ki_ROLLPITCH 0.00101/GRAVITY

    and the roll/pitch seem smooth but I still get wrong values. At roll = 30, I get about 45 on printout and for pitch = 30, I get about 40 deg on the Serial Monitor printout. Anybody else get the same? I know I am actually compiling the new source just by changing the Version printout text slightly e.g. "1.9X" I started with the 1.9.8 download.


  • I have to say, I'm really disappointed in my purchase of this board. I wish the product pages where it's purchasable indicated that the software doesn't work out of the box (so to speak) with v3. Why is the official code not compatible with v3?

    Using the gimbal code at I am able to get mostly good data out of my IMU. I can't, however, get anything worth using out of the real software, even with the fixes mentioned in this thread. The best I have gotten so far is to have roll approach 120 and pitch to go up rather unintuitively while I'm performing pure roll movements. I also get a pile of binary data spew with some occasional new lines thrown into good data.

    For example, just sitting on my desk, I got the following output:

    I am using a v3 with MPU6000_REV_D8 as reported by gimbal-controller.

  • Hi!

    Recently we have bought an arduimu with an GPS (Mediatek), I have downloaded the last version of firmware (1.9.8) and what I get from the device are random values, they change even when the device is stationary, I think is the same problem described here but I'm not sure.

    Could someone confirm if this is the same problem.

    In other case, any idea about this problem?


    Thanks in advance.

  • Hi Guys,

     What if I want to use ArduIMU v3 without GPS (as AHI for OSD) and there is no ground speed. And by this:

    void Accel_adjust(void)
     Accel_Vector[1] += Accel_Scale((GPS.ground_speed/100)*Omega[2]);  // Centrifugal force on Acc_y = GPS ground speed (m/s) * GyroZ
     Accel_Vector[2] -= Accel_Scale((GPS.ground_speed/100)*Omega[1]);  // Centrifugal force on Acc_z = GPS ground speed (m/s) * GyroY

    there is wrong calculation then? How can we fight the centrifugal force without knowing speed?
    Now ArduIMU v3 has main issue: drift while making turn. Seems the centrifugal force is making drift roll axis very bad. Now it shows the G force vector.

    Any input would be great!


  • OK here is the problem description and the solution:

    Problem #1:

    As mentioned above the accelerometer calibration value was incorrect and should be 8192

    // MPU6000 4g range => g = 8192
    #define GRAVITY 8192  // This equivalent to 1G in the raw data coming from the accelerometer

    Problem #2:  DCM algorithm is implemented incorrectly for MPU-6000

    With the previous accelerometer the output for 1G (9.8m/s2) was around 101 so roughly 10 times the raw ADC output.  So in order to accelerate the computations Kp and Ki were adjusted accordingly (divided by 10) and then all calculations were done with the raw ADC data.  Not a pretty way to write code but it worked and marginally accelerated computations.

    However when you raw output was changed by a factor 83.51 for MPU6000 this approach would not work anymore.  It didn't work with the old accelerometer calibration value (4096) and the new value only made matters worse.

    For example:  if the old accelerometer would output value of 1.03 the software would assume it to be 0.1m/s2 now when the new chipset would output the same value of 1.03 the software still infers the value of 0.1m/s2 however actual value measured is 0.0012m/s2.  (the output for 0.1m/s2 from MPU6000 would be 83.51).

    To write it correctly you would have to change  the following lines in the DCM code:

      Accel_Vector[0]=read_adc(3); // acc x
      Accel_Vector[1]=read_adc(4); // acc y
      Accel_Vector[2]=read_adc(5); // acc z

    To  Accel_Scale(read_adc(x)) version and adjust the weight parameters accordingly.  This way it will work fine with any other accelerometer chip and makes the code much easier to read.

    Alternative solution, which I implemented, which still utilizes the marginal acceleration of manipulating the raw ADC values is to adjust the values of Kp and Ki by the factor of 9.81/ACC_MAX_SCALE (10 to make it compatible with the existing algorithm), so by 83.51.

    So the solution would be to change to lines in the initialization code to:

    #define Kp_ROLLPITCH 1.515/GRAVITY
    #define Ki_ROLLPITCH 0.00101/GRAVITY

    This is tested and verified to work correctly.

    Problem #3:

    I just noticed this one while browsing through the code and haven't done anything about it yet:

    #define Accel_Scale(x) x*(GRAVITY/9.81)//Scaling the raw data of the accel to actual acceleration in meters for seconds square

    Can anybody see an issue here?  I'll give you a clue, look and the units.  Does that formula provide a result in m/s2 ?  ...I think not! :)

    Luckily this piece of code doesn't affect anything unless you using GPS and then GPS speed is used to compensate for centrifugal force.  Which I don't have hooked up right now and cannot test.  However if this is an issue for your application I suggest you change it to the correct value and follow it through in the code.

This reply was deleted.


DIY Robocars via Twitter
RT @chr1sa: Donkeycar 4.4 released with tons of new features, including path learning (useful with GPS outdoors), better Web and Lidar supp…
Nov 27, 2022
DIY Robocars via Twitter
RT @NXP: We are already biting our nails in anticipation of the #NXPCupEMEA challenge! 😉 Did you know there are great cash prizes to be won…
Nov 24, 2022
DIY Robocars via Twitter
RT @gclue_akira: レースまであと3日。今回のコースは激ムズかも。あと一歩 #jetracer
Nov 24, 2022
DIY Robocars via Twitter
UC Berkeley's DIY robocar program
Nov 24, 2022
DIY Robocars via Twitter
RT @chr1sa: The next @DIYRobocars autonomous car race at @circuitlaunch will be on Sat, Dec 10. Thrills, spills and a Brazilian BBQ. Fun…
Nov 24, 2022
DIY Robocars via Twitter
RT @arthiak_tc: Donkey car platform ... Still training uses behavioral cloning #TCXpo #diyrobocar @OttawaAVGroup
Nov 20, 2022
DIY Robocars via Twitter
RT @emurmur77: Points for style. @donkeycar racing in @diyrobocars at @UCSDJacobs thanks @chr1sa for taking the video.…
Nov 20, 2022
DIY Robocars via Twitter
RT @SmallpixelCar: Going to @diyrobocars race at @UCSDJacobs
Nov 8, 2022
DIY Robocars via Twitter
RT @SmallpixelCar: Race @diyrobocars at @UCSDJacobs thanks @chr1sa for taking the video.
Nov 8, 2022
DIY Robocars via Twitter
RT @PiWarsRobotics: Presenting: the Hacky Racers Robotic Racing Series in collaboration with #PiWars. Find out more and register your inter…
Oct 23, 2022
DIY Robocars via Twitter
RT @Hacky_Racers: There will be three classes at this event: A4, A2, and Hacky Racer! A4 and A2 are based around UK paper sizing and existi…
Oct 23, 2022
DIY Robocars via Twitter
Oct 23, 2022
DIY Robocars via Twitter
Oct 19, 2022
DIY Robocars via Twitter
Oct 18, 2022
DIY Robocars via Twitter
RT @NeaveEng: Calling all UK based folks interested in @diyrobocars, @f1tenth, @donkey_car, and similar robot racing competitions! @hacky_r…
Oct 13, 2022
DIY Robocars via Twitter
RT @araffin2: 🏎️ After hours of video editing, I'm happy to share a best of my Twitch videos on learning to race with RL. 🏎️ Each part is…
Oct 13, 2022