hongshitan / rtimulib2 Goto Github PK

Hello @HongshiTan
I'm using code from another repo written for teensy, and I rewrote it for Arduino and compiling it for stm32f411.

https://github.com/uutzinger/RTIMULib2-Teensy/

Unfortunately for me, there is no way to discuss code and stuff in this repo.
In the repository

https://github.com/HongshiTan/RTIMULib2/

there is such a possibility, but the RTIMUHal class is a little different, or rather more functional and advanced, but the meaning is the same.
I'm wondering what the case-insensitive read functionality is used for?

 bool HALRead(unsigned char slaveAddr, unsigned char regAddr, unsigned char length,
 unsigned char *data, const char *errorMsg); // normal read with register select
 bool HALRead(unsigned char slaveAddr, unsigned char length,
 unsigned char *data, const char *errorMsg); // read without register select

Actually, I had a problem with compilation when the code had such a strange reading initialization:
I2Cdev::readBytes(slaveAddr, regAddr, length, data, 10)
which I replaced with:
I2Cdev::readBytes(slaveAddr, regAddr, length, data)
And also had to add a new function to the library
I2Cdev.h and I2Cdev.cpp
static int8_t readBytes(uint8_t devAddr, uint8_t length, uint8_t *data, uint16_t timeout=I2Cdev::readTimeout, void *wireObj=0);
But this is not used anywhere in the code, which is why it caused strangeness.
Can someone tell me what this is used for?
I mean, when is regAddr not needed?
P.S. Perhaps this issue can be converted into discussions?

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!

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'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

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

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?

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?