Ouster OS1 IMU Filter 9-DOF

Resolved.

[TixiaoShan]

Have you calibrated your IMU and set the params for them? The z acceleration seems very off from 9.8.

Also, please take a look at closed issues that are labeled as Ouster. Some people had success using OS1 with LIO-SAM.

[TixiaoShan]

It seems that your IMU data is wrong. The z acceleration should be positive. You should read the IMU debug in README to debug your data.

[YushengWHU]

@TixiaoShan This may sound noob, but how do I calibrate an OS1's IMU?

The sensor was mounted on car, what would be the appropriate values for the 2 extrinsic matrices in params.yaml?
I added an imu_transformer node to transform the IMU frame to the Lidar frame and I can confirm in my tests it's working, I guess the IMU and Lidar frames coordination mentioned in the OS1 User Guide (Page 24) won't be necessary anymore, right?

Through trial and error I managed to fix the base_link jumping around to some extent, not sure if the imu_transformer fixed it or what but I'm getting better results and now the point clouds are only inconsistent in the Z axis! They are drawn stacked and each one beneath the other!

As for the extreme Z acceleration values, I tested the same configuration with a sample OS1-64 dataset (the OS1-64_city1.bag file to be exact) from Ouster's website, and both give negative values and produce similar results! As you can see in the screenshots. Could it be that Ouster also had uncalibrated IMU during their recording?!

Ouster's sample dataset:

IMU acc: 
x: -1.33836, y: -1.30723, z: -8.65025
IMU gyro: 
x: 0.00146476, y: 0.00798948, z: -0.00599211
IMU roll pitch yaw: 
roll: 0.14283, pitch: -0.159687, yaw: -1.50263

IMU acc: 
x: -1.4054, y: -1.05345, z: -8.69095
IMU gyro: 
x: 0.00772319, y: 0.00812262, z: -0.00865527
IMU roll pitch yaw: 
roll: 0.142914, pitch: -0.159369, yaw: -1.50259

My dataset:

IMU acc: 
x: -0.512359, y: -0.433351, z: -10.3693
IMU gyro: 
x: -0.0226369, y: 0.01012, z: 0.0198406
IMU roll pitch yaw: 
roll: 0.0256961, pitch: -0.00256328, yaw: -1.65608

IMU acc: 
x: -0.344765, y: 0.3304, z: -10.228
IMU gyro: 
x: -0.0242348, y: 0.00932106, z: 0.0234358
IMU roll pitch yaw: 
roll: 0.0256843, pitch: -0.00196913, yaw: -1.6563

I applied the suggestions from issues #94 and #100 (plus cleaning and recompiling each time) but none produced any working solution!

Here's a sample rostopic delay output for my dataset:

WARNING: may be using simulated time
average delay: 1597566914.173
	min: 1597566914.168s max: 1597566914.178s std dev: 0.00299s window: 20
average delay: 1597566914.174
	min: 1597566914.168s max: 1597566914.182s std dev: 0.00359s window: 40
average delay: 1597566914.174
	min: 1597566914.166s max: 1597566914.184s std dev: 0.00387s window: 60
average delay: 1597566914.174
	min: 1597566914.166s max: 1597566914.184s std dev: 0.00371s window: 80
average delay: 1597566914.174
	min: 1597566914.166s max: 1597566914.184s std dev: 0.00383s window: 100

Another odd thing is, I get no messages from any of the /odometry/imu, /odometry/gps, /odometry/gpsz, /gps/fix or /gps/filtered topics! Only /odometry/filtered and /odometry/navsat output messages.

Here's my complete src folder, if you wanted to take a look:
src.zip

Note: If you're interested in trying the Ouster's sample dataset, you have to remove the "/" prefix from the imu frame id. You can clone this repository and run:
rosrun autoware_bag_tools change_frame_id.py -o out.bag -i /path/to/sample-data-1.13_OS1-64_OS1-64_city1.bag -t /os1_cloud_node/imu -f os1_imu

I agree with the author, I can show u the picture when I miset the IMU coordinates

[YushengWHU]

@YushengWHU Okay so how did you solve this? Can you tell me your parameters?
The dataset in the screenshots is a sample from Ouster, you can get it from here, in that page there's also a sample_config_file.json that contains information for Lidar and IMU frame coordination for that dataset as described in the OS1 User Guide (Page 24). I tried every combination of those values but none fixed this issue!
P.S: I fixed the negative Z acceleration and reported above, but still it keeps descending!

everything followed what Mr.Shan told me above, and did an extra calibration of IMU, followed an closed issue of LioSam

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[HappySamuel]

Hi @YushengWHU

Can you share the ROS package that you use for calibrating IMU?

Best,
Samuel

[YushengWHU]

I ended up purchasing an INS unit (XSENS MTi-680G IMU+GNSS) and as it seems I have a new problem with synchronizing the Ouster LiDAR and XSENS IMU!
I have contacted support and they said I can only get the GPS data if I integrate them through the Ouster's Interface Box and no IMU data! I tested and I get jerky movement and sudden jumps, and as it is mentioned in the README.md it's because of the un-synced timestamps between LiDAR and IMU messages, is there anyway I can manually sync them by reading the bag file and exporting it to new one?

I am using MTI 680G with Ouster OS1-64, 680G is using ros time and you can get the GPS data in ros time timestamp, you dont need to use Ouster interface box, what you need to do is simply PTP sync.
Refererring to the second question, you cant sync them now.

[YushengWHU]

I'm puzzled! So MTi-680G can be connected to the USB port and Ouster OS1 is connected to the Ethernet port, how are they in sync in your setup while not connected to each other? And I believe you're referring to PTP Sync by the Ethernet chipset (which my Ethernet does not support) regarding the Ouster, that still leaves the MTi-680G in the equation, am I right?

Can you please elaborate?

sure， the mti-680g is connected via USB port and the Ouster via Ethernet port, and I am using a DJI manifold 2C for calculation, which support PTP sync. As mti-680G is already synced with ROS time, the only thing is PTP sync Ouster.

[YushengWHU]

Thank you for the reply and sorry for all the bothering, do you think it's also possible with an ordinary Linux laptop? I checked for PTP support on the Ethernet chip and it seems I'm out of luck:

Time stamping parameters for enp3s0:
Capabilities:
	software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
	software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
	software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes: none
Hardware Receive Filter Modes: none

Is there any other way to sync these 2 sensors?

Thanks in advance.

As described in the user manual, PTP sync is the simplest and the most recommanded way of sync measure. If your PC cant do a PTP sync, the only way, I suppose, is hardware sync through interface box.

[YushengWHU]

For future visitors, if anyone wants to sync the Ouster with a NIC that does not support hardware timestamps, follow these instructions:

1. sudo apt install ptpd
2. Connect your sensor and wait for the connection to get stable
3. sudo ptpd -i enp3s0 -M -V
4. Wait for 140 seconds and you'll
5. Set the sensor to TIME_FROM_PTP_1588 timestamp mode and reinitialize

You now have PTP sync with your Ouster.

Exactly, I followed this instruction to sync my ouster with ros

[Cracks-ll]

@hummblebee hello, For imu, what driver are you using? Is it the official xsens_ros_mti_driver?
I use it, but the timestamp of the topic "/imu/data" is wrong! I see your timestamp is right.
Do you know what caused my error?