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.
Last updated
Was this helpful?
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.
Last updated
Was this helpful?
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.
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.
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.
Data sent by server are a dictionary and the axes are those defined by the physical sensor on the robot
{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 are processed and then published on the topic /imu/data_raw. The axis orientation is the same as PixHawk in the BlueRov2 configuration.
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.
There are two calibration files, one for each adafruit IMU. For each parameter, the result after calibration is :
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.
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 :