💡
aColor-BlueRov2
  • aColor-BlueRov2 ROS implementation
  • Topside computer
    • Required configuration
    • File system and ROS architecture
    • Launch ROS implementation
    • ROS-MAVlink bridge
    • Controllers
      • Depth control
      • Heading control
      • Velocity control
      • Gamepad
    • Commander
    • Graphical User Interface (GUI)
      • GUI modification
    • Additional IMUs : client
  • Companion computer
    • Required configuration
    • Additional IMUs : server
  • ArduSub
    • ArduSub parameters
  • MAVlink message
    • Pymavlink
  • Configure new frame
    • Custom Ardusub 3.5
  • Bibliography
    • Bibliography
Powered by GitBook
On this page
  • About IMUs
  • Why 2 IMUs ?
  • Raw IMU data computation
  • Imu_bridge.py
  • Receiving data
  • Data received format
  • Data published on the topic /imu/data_raw
  • Data Processing

Was this helpful?

  1. Topside computer

Additional IMUs : client

There are two additional IMUs inside the BlueRov2 to try to get a good estimation of the velocity. Description of the file Imu_bridge.py and Imu_bridge.py.

PreviousGUI modificationNextRequired configuration

Last updated 5 years ago

Was this helpful?

About IMUs

IMU stands for Inertial measurement unit, they are pretty common sensors for robotics application and of course used on the BlueROV2.

The BlueROV2 has 2 kinds of IMU:

  • 1 PixHawk IMU for heading estimation

  • 2 Adafruit LSM9DS1

    IMUs for velocity estimation

The IMUs used have 9 DOF: 3 angular velocities, 3 linear accelerations, 1 magnetometer.

With those data it is possible to compute an orientation quaternion, later used to calculate Euler angles.

Why 2 IMUs ?

We used 2 IMUs in order to take the mean value, and therefore gain in accuracy. It is also possible to use least squares approximation.

Raw IMU data computation

Data from relatively cheap IMU are very noisy. The predominant error and noise sources are:

  • constant bias error: average output of the device over a specified time, there are 2 parts one deterministic part called bias offset and a random part. The bias offset can be determined by calibration. The random part is a stochastic process and refers to the rate at which the error in an inertial sensor accumulates with time.

  • bias instability: random variation in the bias computed over a finite sample of time

  • angle random walk (gyros): white noise

  • velocity random walk (accelerometer): white noise

To improve the quality of raw data we implemented an exponential filter (low-pass filter to cut white noise) and we did the calibration of the IMUs to remove the bias offset. However we could not get rid of the random bias, which cause a drift after integration.

A solution to solve the issue would be to fuse IMU acceleration data with an other measurement of velocity from an other sensor (DVL, GPS...) in a Kalman filter. The IMU give a good short time estimation that needs to be corrected after a while with low frequency sensors, as GPS.

Imu_bridge.py

Imu_bridge_raw.py runs like Imu_bridge.py but doesn't do calibration. Only raw data are published on /BlueRov2/imu/imu1_raw, /BlueRov2/imu/mag1_raw for IMU1, /BlueRov2/imu/imu2_raw, /BlueRov2/imu/mag2_raw for IMU2.

Receiving data

Data received format

Data sent by server are a dictionary and the axes are those defined by the physical sensor on the robot

In our case IMU1 is the first IMU, IMU2 is the second with SDOM and SDAG connected to the ground

{IMU1:{"time": t, "accel_x": accel_x, "accel_y": accel_y, "accel_z": accel_z, "mag_x": mag_x, "mag_y": mag_y, "mag_z": mag_z, "gyro_x": gyro_x, "gyro_y": gyro_y, "gyro_z": gyro_z, "temperature": temp}, IMU2:{"time": t, "accel_x": accel_x, "accel_y": accel_y, "accel_z": accel_z, "mag_x": mag_x, "mag_y": mag_y, "mag_z": mag_z, "gyro_x": gyro_x, "gyro_y": gyro_y, "gyro_z": gyro_z, "temperature": temp}}

Data published on the topic /imu/data_raw

Data are processed and then published on the topic /imu/data_raw. The axis orientation is the same as PixHawk in the BlueRov2 configuration.

Data Processing

First data are organized to fit the PixHawk IMU configuration. Then they are calibrated according to the calibration file. Finally they are filtered by a IIR low pass filter.

Calibration process

There are two calibration files, one for each adafruit IMU. For each parameter, the result after calibration is :

CalibratedValue=(MeasuredValue−offset)/scaleCalibrated Value = (Measured Value - offset)/scaleCalibratedValue=(MeasuredValue−offset)/scale

Calibration file

{
"acc_unit" : "m.s^-2", 
"acc_off_x" : 0.363, 
"acc_off_y" : 0.016,
"acc_off_z" : -0.070,
"acc_scale_x" : 1,
"acc_scale_y" : 1,
"acc_scale_z" : 1,

"gyr_unit": "degrees per second",
"gyr_off_x" : -4.64 , 
"gyr_off_y" : 3.39,
"gyr_off_z" : 0.772,
"gyr_scale_x" : 1,
"gyr_scale_y" : 1,  
"gyr_scale_z" : 1,

magn_unit: "gauss",
magn_off_x : -0.672,
magn_off_y : -0.241,
magn_off_z : -0.514,
magn_scale_x : 0.376,
magn_scale_y : 0.409,
magn_scale_z : 0.475
}

In the example of a calibration file, acc is for acceleration values, gyr for gyroscope values, and magn for magnetic value, off means offset and scale is for scale.

For accelerometer and gyroscope we recorded data when the ROV was motionless. We averaged for each axis. The average value is our offset. and the scale is 1.

IIR filter

y[n]=a∗x[n]+(1−a)∗y[n−1]y[n] = a*x[n] + (1-a)*y[n-1] y[n]=a∗x[n]+(1−a)∗y[n−1]

Where y is the output and x the measured vector, a is the smoothing value. In our case a = 0.3.

The code operate as client which subscribed to a running on Raspberry Pi. There is no data processing on the Raspberry Pi. The client requests data by sending "?" to the server and the server answer by sending IMUs data. They communicate at 100 Hz.

Calibration files are in the folder imu_i2c/calibration ()

To calibrate the magnetometer we used a modified version of FreeIMU GUI calibration tool :

https://upcommons.upc.edu/bitstream/handle/2117/103849/MScLeslieB.pdf?sequence=1&isAllowed=y
server
https://github.com/nathanfourniol/FreeIMU-gui-ROS
File structure
PixHawk and IMUs axis configuration