hongshitan / rtimulib2 Goto Github PK

After calibrating either using RTQF or Kalman, covariance matrix is not generated. I have tried calibration both through RTIMULibCal and RTIMUDemoGL, and the RTIMULib.ini generated does not contain the covariance matrix for linear acceleration, orientation and angular velocity. Does this library generate the covariance matrices or should it be filled in through some other method?

Hi there, I am trying to calibrate the following Sparkfun IMU/MAG SparkFun 9DoF IMU Breakout - ISM330DHCX, MMC5983MA, the device is not detected, I get the following:

$ RTIMULibCal
RTIMULibCal - using RTIMULib.ini
Settings file RTIMULib.ini loaded
Failed to open SPI bus 0, select 0
Failed to open SPI bus 0, select 1
No IMU detected
Using fusion algorithm RTQF
No IMU found

Devices are detected here

$ sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: 30 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- 6b -- -- -- --
70: -- -- -- -- -- -- -- --

From the hookup-guide there is sample code to be used on an Arduino, I am using a rpi3 with Ubuntu 20.04.

I was hoping you can point me feasibility to add a new device to the list and make it work? Not sure where and what to modify? From the previous link the libraries are here

• ISM330DHCX Arduino Library
• MMC5983MA Arduino Library

thanks in advance, regards

Hi, I am trying to use RTIMULib2 on a Raspberry Pi model 3B+ running Ubuntu 20.04 with an SPI attached LSM9DS1 IMU. After compiling and installing the library, I get this output whenever I run RTIMULibDrive:

Settings file RTIMULib.ini loaded
********************************************verison : 1.2
Using fusion algorithm RTQF
min/max compass calibration not in use
Ellipsoid compass calibration not in use
Accel calibration not in use
Incorrect LSM9DS1 accel/mag id 104

The modified parts of RTIMULib.ini are:

# #####################################################################
# 
# RTIMULib settings file

# General settings
# 

# IMU type - 
#   0 = Auto discover
#   1 = Null (used when data is provided from a remote IMU
#   2 = InvenSense MPU-9150
#   3 = STM L3GD20H + LSM303D
#   4 = STM L3GD20 + LSM303DLHC
#   5 = STM LSM9DS0
#   6 = STM LSM9DS1
#   7 = InvenSense MPU-9250
#   8 = STM L3GD20H + LSM303DLHC
#   9 = Bosch BMX055
#   10 = Bosch BNX055
#   11 = HMC5883L + ADXL345 + L3G4200D
IMUType=6

# 
# Fusion type type - 
#   0 - Null. Use if only sensor data required without fusion
#   1 - Kalman STATE4
#   2 - RTQF
FusionType=2

# 
# Is bus I2C: 'true' for I2C, 'false' for SPI
BusIsI2C=false

# 
# I2C Bus (between 0 and 7) 
I2CBus=1

# 
# SPI Bus (between 0 and 7) 
SPIBus=0

# 
# SPI select (between 0 and 1) 
SPISelect=0

# 
# SPI Speed in Hz
SPISpeed=500000

# 
# I2C slave address (filled in automatically by auto discover) 
I2CSlaveAddress=107

If the IMU is connected on the I2C bus, RTIMULib works correctly.

Using AccelGyroMag.py and modifying lsm9ds1.py on lines 34 and 35, where SPI device is 0 for Accelerometer and Gyroscope and 1 for the Magnetometer, works. So I am assuming it is not a SPI port configuration issue.

If there is some information missing just let me know and I add as needed.

Thanks in advance!

I'm struggling to see why the orientation is handled the way it is for the MPU9250 (and similarly for the MPU9150), and have been getting unexpected outputs from the fusion with an offset on the z axis.

The relevant lines are:

Natively, the compass follows a North-East-Down (NED) frame convention, while the accelerometer and gyroscope is using East-North-Up (ENU) convention:

As RTIMULib expects the default orientation to be NED, I would have expected the accelerometer and gyroscope to have their x and y axis swapped and z axis flipped to bring it into the same orientation as the compass which is already in NED.

With the current solution, the y and z axis of the gyroscope is flipped which also brings it into NED, but 180 degrees offset from the native compass orientation:

The accelerometer only has its x axis flipped with its z axis left pointing up. Which neither follows NED nor ENU.

The compass has its x axis flipped then swapped with the y axis. Effectively rotating them 90 degrees, but it does not add an accompanying 90 degree offset on the z axis.

I might be misunderstanding completely, and am not very familiar with the core RTIMULib library codebase. What's the reason it's been done this way?

I was recently discovered that there is now a cpp calibration programme for the ellipsoid fit in this repo of RTIMULib2. This is great news.

Is anybody working on using it instead of the Octave (matlab) code from the calibration functions? I am happy to work on this but would prefer to avoid duplication of effort!

I've generated RTIMULib2 bindings to rust

https://github.com/bareboat-necessities/rust-modules/tree/main/RTIMULib2/Linux/rust

It would be better if this code could be a part of RTIMULib2 (same way as python code)

ReadMe: https://github.com/bareboat-necessities/rust-modules/blob/main/RTIMULib2/Linux/rust/readme.md

Thanks