[Solved] MPU9250 Driver for ROSBot


I use your library for the MPU9250 in my own robot:

  • what is the orientation of the chip in ROSbot?
  • as result für the IMU acceleration I get 0 (more or less) in all directions, but expected at least 1g in one direction for gravity. Also in the “ekf_params.yaml” configuration the parameter for removing gravity is set to true. Is the gravity substracted somewhere in the library and I did not find it or did I miss something?



Hi Michael

  • It depends on when you bought the robot. The previous version has the MPU9250 or MPU9255 sensor. We’ve been assembling ROSbots with BNO055 senor for three months now. There is no difference in the way you use it becouse the firmware ensures the correct orientation of the output quaternion (MPU925X and BNO055 code). You can find information about your sensor after starting ROSbot.

    You can find information about the position of the chip in ROSbot below:

  • It depends on what sensor you are using. There are two ways:

    • BNO055 - there is a function in the library that reads the sensor and returns the data. You can specify the type of reading like in this line. SENSOR_TYPE_LINEAR_ACCELERATION variable (link) provides type of reading where acceleration doesn’t include gravity.

    • MPU9250 - you can read in MPU9250 dockumentation:

      When the device is placed on a flat surface, it will measure 0g on the X- and Y-axes and +1g on the Z-axis. The accelerometers’ scale factor is calibrated at the factory and is nominally independent of supply voltage.

      But there is Digital Motion Processor Arduino Library (DMP) that implements motion processing functions of MPU-9250. It converts the signal between the sensor and the register from which the data is read.


Hi Paweł,

thanks for your detailed answer.
I don’t have a ROSbot but a similar robot based on Core2. I used some code snippets from ROSbot to understand the mbed functionality together with Core2.
The 9250 results from your implementation are more or less zero in all directions, my implementation for the 6050 has +1g in z-direction. in the Preparing Your Data for Use with robot_localization document is described how to use the acceleration for getting the correct orientation, so I don’t want to remove it (first).
And the code positions you mentioned in your unedited post I could not found (at least I did not expect them in the bias functionality).
When I looked in the parameters for the rosbot_ekf package https://github.com/husarion/rosbot_ekf/blob/master/params/ekf_params.yaml I saw that the parameter

imu0_remove_gravitational_acceleration: true

is set, which does not fit together (at least in my understanding).


Hi Paweł,

I looked a little bit deeper in the code and it is a little bit strange for me:
The function “get_st_biases” in “inv_mpu.c”, you mentioned in your post for subtracting the gravitty, is only called by the “mpu_run_self_test”, which is called by “resetDMPgyro” and “run_self_test”, which are never called in ROSbot firmware. So how can the result of acceleration be 0 on a flat surface?
Or did I miss something?



Hi Michael,
Sorry it took so long, but we find some odd behavior with IMU sensors in ROSbot. We made a few changes becouse the gravity vector was scaled incorrectly. You may have seen value of acceleration equals 1.0 (i.e. [g] unit) when it was 9,81 m/s^2 in real, so we change unit by changing BNO055 accel_scale in ImuDriver.cpp file. Now our code is fully complies with the REP 103 ROS standard. Whats more, we changed DMP configuration (MPU) and data vector type (BNO) and gravity vector is included now, so it is desirable now to seeing 9.8 m/s^2 when robot stay on a flat surface

The imu0_remove_gravitational_acceleration in rosbot_ekf parameter is information for the Kalman filter that lead to remove gravity vector. That it is clearer now, I hope.

You can find now the newest version of rosbot_ekf package and the newest firmware 0.15.0 tag. By analyzing this commit, you are able to find so answers on your questions.

Best regards,

Hi Paweł

Thanks again for your answer.
I will change my code and look at the results.
In my implementation of the MPU6050 I executed the self test rountine and the results seems to be a little bit better as without. Maybe it’s worth to test it with the 9250 too :wink:.