Migrating from QVIO to OpenVINS (SDK1.6)
-
Hi Modal,
Cleo is in the evaluation phase of switching from QVIO to OpenVINS (specifically version https://gitlab.com/voxl-public/voxl-sdk/services/voxl-open-vins-server/-/tags/v0.5.7). As part of this process, I would like to gather the latest information from the VOXL-OpenVINS developers regarding what to expect in terms of relative performance moving from QVIO to OpenVINS. Additionally, are there any platform/airframe specific tuning routines (besides of course cam<->imu extrinsics and cam intrinsics)? We have a very different airframe than the starling
https://cleorobotics.com/specifications/Some general areas that come to mind that we didn't touch on QVIO but might be relevant to OpenVINS:
- IMU static intrinsics (calibrated once)
- IMU dynamic calibration (ie temperature based)
- IMU noise tuning
- IMU<->Camera time synchronization
- Synchronization of 3 camera frames (we have 3 non-overlapping tracking cameras)
- The parameters in the different https://gitlab.com/voxl-public/voxl-sdk/services/voxl-open-vins-server/-/tree/master/misc_files/usr/share/modalai/voxl-open-vins/VoxlConfig?ref_type=heads files, which I noticed were not the same.
I'm sure I'm forgetting other areas that could affect OpenVINS performance, I'm by no means a CV or filter expert
Overall, we want our migration to be as seamless as possible and result in the best performance of OpenVINS as possible on our airframe with our sensor suite. Your assistance in this is very much appreciated! -
Tagging people who might have the most context here: @Cliff-Wong @Clifford-Wong @zauberflote1, any comments / studies on comparative performance, as well tuning routines to get the best performance out of a running OpenVINS on a new airframe?
Perusing posts about OpenVINS from the past year: https://forum.modalai.com/search?matchWords=all&in=titles&showAs=posts&replies=&repliesFilter=atleast&timeFilter=newer&timeRange=&sortBy=topic.lastposttime&sortDirection=desc&term=openvins I found some information about drifting and how to address it. But I'm not sure if that's the most up to date advice, it looks like the module is still under active development. Is the module in a place where it is ready for general customer use? The starling2 drones that ship with SDK1.6 use OpenVINs for localization, not QVIO, correct?
Thank you for any input!
-
Hi Modal,
Just following up here, I am going to put our migration to OpenVINS onto the backlog for the time being. Please let me know when the SDK is ready for QVIO -> OpenVINS migration, and when there is bandwidth to assist us with the migration. You can reach me at rowan.dempster@cleorobotics.com.
-
@Rowan-Dempster Hi there,
Glad to hear you are exploring the new voxl-open-vins-server.A few things to consider, as you are not using a "ModalAI airframe".
- OpenVINS follows the classic Kalibr calibration model (both cameras and IMU)
- Calibration involves IMU intrinsics, Cam Intrinsics, IMU-CAM extrinsics
From this point, I'll assume you're using a VOXL2 Board. Hence, your IMU intrinsics should be "1:1" to the values reported in here. However, depending on your airframe vibration you may need to tune the noise density and random walk values -- Personally, I would leave this as a final option, as these are a result of extensive calibration routines and have shown to be invariant among our airframes.
Moreover, you can obtain the camera intrinsics using our voxl-camera-calibration repo. I highly recommend to re-calibrate your cameras, making sure your reprojection error is in the subpixel range.
Next, we need the extrinsics from each CAM to IMU. Ideally, you may want to run Kalibr or you can use the sync_config flag in /etc/modalai/voxl-open-vins-server.conf as true under the assumption your extrinsics.conf is setup correctly. If you opt to use Kalibr, you will need to update the camchain file and make sure your sync_config flag is set to false.
Finally, we need to address the most important config file. Tuning this file may be a bit challenging because it revolves around use-case that being said, I would leave as is for the most part, addressing ZUPT params and chi2_multipliers/sigma_px based on simple hand-held tests. Particularly, if the estimator blows up when the drone is sitting still right after a power-cycle -> ZUPT params, and/or if due to heavy dynamic motion MSCKF features are losing track frequently or the platform is drifting slightly -> Bump chi2_multiplier + increase/decrease (case-by-case) sigma_px (SLAM/MSCKF).
To conclude, I would recommend deactivating the thermal calibration of the IMU for initial testing, as depending on the SDK version and platform, it could increase the perceived noise in the accel. Also, I would attempt 2Cam flights using ION pipes (vio_cams.conf) before jumping to 3Cam, as the 3rd Cam seems to add more noise into estimator if placed in opposite direction to another Cam (e.g., front and rear) and the extrinsics are not "perfectly" tuned.
PS: We have a converter from voxl-logs to rosbags for seamless integration with Kalibr, feel free to check it out
PS2: Regarding camera time-synchronization, if your cameras are being driven by an fsync line, you shouldn't have to worry about the sync dt; however, if they are not, you may want to bump the fusion_rate_dt_ms flag (voxl-open-vins-server.conf) to a value that guarantees that every camera has one individual frame. Moreover, if the timestamps are not monotonically increasing or the cameras don't start exposing at the same time -- implying that the 3Cams have non-aligned timestamps, you may need to "hot-fix" your timestamps to get a stable performance. As for the CAM-IMU dt, we use the online calibration inside of our OpenVINS implementation to estimates the value.
PS3: We currently don't have any external-release report for performance comparison with QVIO, but internally we have seen significant differences in behavior between the two (especially in multi-camera setups and under aggressive motion). In general, OpenVINS gives you more tuning flexibility and multi-camera support, at the cost of being more sensitive to calibration quality.
-
To clarify, our current platforms are shipped with voxl-open-vins-server as the default VINS solution; however, QVIO is still available (SDK 1.6.2).
