Non-overlapping triple mono cameras with IMU

[gfr-misha]

Thank you for your amazing work. I am eager to try it out on our use case. We have a drone with triple non-overlapping cameras, and we'd like to estimate odometry with it accurately (and potentially have full SLAM system). Could you please clarify if that can work reliably with this package? If so, which parts could be challenging?

I had a look at the paper and it mentions multi-camera support, but it was unclear to me to which extent.

Thank you in advance!

[1fwang]

Maybe you can look at the file: config / hilti_challenge_2022.yaml. It shows how to use mutiple cameras setup. I think you could change the calibration param and subscibed topic to verify your idea. The challenging part might be the extrinsic calibration results, I'd like to recommand to also turn on online calibration function at beginning, see if the system can runs properly.

Thank you for your amazing work. I am eager to try it out on our use case. We have a drone with triple non-overlapping cameras, and we'd like to estimate odometry with it accurately (and potentially have full SLAM system). Could you please clarify if that can work reliably with this package? If so, which parts could be challenging?

I had a look at the paper and it mentions multi-camera support, but it was unclear to me to which extent.

Thank you in advance!

[gfr-misha]

Thanks for your reply! I managed to run Hilti example successfully. Issue that I'm having with my dataset mentioned here (#5) might be related to camera-imu time synchronization. Is there anything specific that should be done in order to have a valid sensor data?
I get the following message at the start up:

[okvis_node_synchronous-1] W20241106 14:24:46.938369   381 ThreadedSlam.cpp:290] startup: dropping frame because IMU measurements are newer, t=1729618358.237166808

[SebsBarbas]

The challenging part of your setup is to obtain an accurate scale of the system if there is no overlap between cameras since you rely on the IMU.

As for your problem, I recommend looking at the different queues in OKVIS2. There seems to be a full and blocking queue, which does not allow further data processing. My recommendation would be to add some simple prints to see if this is happening (e.g., a lack of IMU data for a couple of seconds, so the camera data is not further processed).

Another option would be to run your data with the subscriber to a ROS2 rosbag.

If you have further insights, please share!