How can the odometry messages be published at the IMU frequency?

[wagdeer]

Hello, I really appreciate your work! I'm currently testing it on the Livox Mid360, and I've noticed that the current odometry messages are published at the LiDAR sensor's frame rate. Are there any plans to switch to publishing odometry at the IMU frequency instead? I'd like to use it for robot navigation, and I'm looking forward to your reply!

[mehermvr]

Hi, thank you for trying out rko lio and the question.
Currently, there is no way to publish at IMU frequency. I have considered how this can be done, but with the current implementation it would require quite a bit of additional rewrite/effort (more details below). Therefore, it hasn't been a big priority for me. Until now, the requirement also hasn't come up.

Hence, I'd like to better understand your needs. Especially to see if this is a general use case.
Where and how exactly would such a higher frequency odometry be useful to you? The odometry can definitely work at lidar frame rate, (typically) 10 Hz. I get that control modules might be running at higher frame rates, but the pose or velocity would not really change that much over a 0.1 sec window (also an assumption that the odometry uses). And if required, a simple extrapolation into the future based on the available velocities should be enough I think. Is 10 Hz really insufficient?

Nevertheless, the only way I can publish odometry at IMU frequency is to integrate IMU messages over the last estimated LIO pose. This "IMU integrated pose" would then be reset to the LIO pose once a lidar scan is registered. New IMU messages will be integrated over this corrected pose. And repeat.
Would something like this be enough for your needs? Before I go ahead and do some changes for that (once i can work on this, will take some time).

Following are more details in case you're interested in how the odometry works right now and why the IMU frequency pose is a problem to implement as is.
Consider you have a 50 Hz IMU and a 10 Hz lidar. An illustration of how the data is coming in can be

IMU:   1-2-3-4-5-6-7-8-9-10-11-12-13-...
Lidar:         5         10          ...

The numbers are not really message timestamps, but just to indicate there should be a lidar message every 5 imu messages if everything is perfectly in sync. But this is typically not the case, and even if the sensors are referring to the same clock, there might be some delay in arrival of the messages. Typically it's the lidar thats delayed.
So something like

IMU:   1-2-3-4-5-6-7-8-9-10-11-12-13-...
Lidar:               5      10       ...

I've also seen the opposite where its the IMU thats delayed and not the lidar.

No delay on either sensor is actually the rarer situation.
To handle this, what I do by default is to buffer both messages and wait until the IMU messages cross the last available lidar message or keep buffering the IMU until a lidar becomes available. Then i process all the messages in a batch. for example, once lidar 5 is available and IMU 1-5 are available, i process all that data at once. Similarly for Lidar 10 and IMU 6-10. This makes the odometry resilient to network or message arrival delays up to an extent. But this batch processing also means that the odometry can only run and publish a pose as fast as the Lidar messages come in. To publish an IMU rate pose, I'd have to either disable this buffering, or provide an alternate solution. Hence, why I say it would required additional effort.

[wagdeer]

Thank you very much for your detailed answer — it was really helpful to me. The approach you mentioned about increasing the odometry publishing frequency is something I’ve also seen commonly used in many visual-inertial odometry systems. I ran some additional experiments today as well: on my wheeled robot platform with Navigation2, running odometry at 10 Hz doesn’t seem to cause any noticeable issues. I’m just not sure how this would translate to UAVs — would they typically require a higher odometry frequency for stable performance?

[mehermvr]

Good to hear that your experiments worked out. I would expect 10 hz to be fine as well, as long as one doesn't run into any tf extrapolation errors.

I'm not sure about the requirements for drones, as that's the one platform i haven't really tested. Finding good quality data for drones also seems a bit hard, and i myself dont have a drone to use to test/record. Still, there's some ideas i have for testing there, but its a bit low priority for me right now.

I did think more on how i can do the higher frequency publishing though, probably in a few weeks.

[xbkaishui]

@wagdeer Hello, can you share your mid360 config file. I want to test it