Problems in resetting voxl-open-vins-server
-
Hi,
In Voxl2 (SDK 1.4.1), I'm using voxl-open-vins-server for odometry and testing the auto-reset functionality. When OV detects that a reset is needed, it correctly performs the reset. However, after that, problems start to arise: the VIO keeps resetting because the x, y, and z positions diverge.
In some cases, the quality drops below -1% (e.g., -200%), and the reset doesn't even trigger. Only in a couple of tests did the functionality work as expected, but I haven't been able to determine the exact conditions under which this happens.
Has anyone else encountered this issue?
-
Hello Marco,
Thanks for your question.A few things to consider:
What is your camera setup -- or is it a ModalAI development drone?Note that the default configuration of voxl-open-vins-server does not use dynamic initialization, meaning that if a reset triggers while the platform has some motion above the maximum threshold, OV won't be able to properly re-initialize.
If you want to test if that is the case, set "init_dyn_use" to true in the voxl-open-vins-server.confTo further diagnose the issue, please do the following:
- Run voxl-open-vins-server from terminal
voxl-open-vins-server- Check why the reset was triggered based on the output
- Analyze the following messages post unsuccessful re-initialization -- usually, motion issues will be characterized by IMU threshold messages
- If the problem persists, upload your voxl-open-vins-server.conf file
-
Hi, thanks for your response!
I'm using a ModalAI development drone (Starling2), and to make the VIO less robust and test the auto-reset, I'm only using the tracking_front camera.
I have already set "init_dyn_use" = true and "en_force_init" = true.
However, whether "en_force_init" is set to true or false, the result is always the same: the system resets, but as soon as it restarts, it immediately begins to diverge, causing another reset shortly after, and so on. After a certain number of resets, it sometimes stops resetting and continues to diverge indefinitely.The only way the reset works without the VIO diverging afterward is if the reset happens while the drone is placed on a stable surface.
This is my config file:
{ "en_auto_reset": true, "auto_reset_max_velocity": 20, "auto_reset_max_v_cov_instant": 0.10000000149011612, "auto_reset_max_v_cov": 0.10000000149011612, "auto_reset_max_v_cov_timeout_s": 0.5, "auto_reset_min_features": 1, "auto_reset_min_feature_timeout_s": 3, "auto_fallback_timeout_s": 3, "auto_fallback_min_v": 0.600000023841858, "en_cont_yaw_checks": false, "fast_yaw_thresh": 5, "fast_yaw_timeout_s": 1.75, "do_fej": true, "imu_avg": true, "use_rk4_integration": true, "cam_to_imu_refinement": true, "cam_intrins_refinement": true, "cam_imu_ts_refinement": true, "max_clone_size": 8, "max_slam_features": 35, "max_slam_in_update": 10, "max_msckf_in_update": 10, "feat_rep_msckf": 4, "feat_rep_slam": 4, "cam_imu_time_offset": 0, "slam_delay": 1, "gravity_mag": 9.80665, "init_window_time": 1, "init_imu_thresh": 1, "imu_sigma_w": 0.00013990944749616306, "imu_sigma_wb": 4.1189724174615527e-07, "imu_sigma_a": 0.0038947538150776763, "imu_sigma_ab": 5.538346201712153e-05, "msckf_chi2_multiplier": 0.65, "slam_chi2_multiplier": 40, "zupt_chi2_multiplier": 1, "msckf_sigma_px": 1, "slam_sigma_px": 1.8, "zupt_sigma_px": 1, "try_zupt": true, "zupt_max_velocity": 0.03, "zupt_only_at_beginning": true, "zupt_noise_multiplier": 1, "zupt_max_disparity": 8, "init_dyn_use": true, "triangulate_1d": false, "refine_features": false, "max_runs": 5, "init_lamda": 0.001, "max_lamda": 10000000000, "min_dx": 1e-06, "min_dcost": 1e-06, "lam_mult": 10, "min_dist": 0.1, "max_dist": 60, "max_baseline": 40, "max_cond_number": 600000, "use_mask": false, "use_stereo": false, "use_baro": false, "num_opencv_threads": 4, "fast_threshold": 10, "histogram_method": 1, "knn_ratio": 0.7, "takeoff_accel_threshold": 0.5, "takeoff_threshold": -0.1, "use_stats": false, "max_allowable_cep": 1, "en_force_init": true, "en_force_ned_2_flu": false, "track_frequency": 30, "publish_frequency": 15, "en_vio_always_on": true, "en_ext_feature_tracker": false, "en_gpu_for_tracking": true, "num_features_to_track": 30 }Also, I am keeping "en_vio_always_on" = true because i am performing hand testing. But if i set it to false, the VIO never starts (from voxl-inspect-vins I see it is at 0,0,0 and the the portal I do not see any feature on ov_overlay if i move the drone).
Any suggestion? Thanks again!
-
@Marco-Spangaro
From your test case description, there could be a few reasons for an imperfect re-initialization. Please note that monocular VINS has four unobservable directions (position and yaw), so your hand motion could likely affect initialization, especially if you are moving too erratically or performing a degenerate motion that would affect the calibration refinement.Note that if the image frames post-reset are not feature-friendly, they could also have a negative impact.
Regarding the vio_always_on flag, some segments of the voxl-open-vins-server code will only be executed if the drone is armed or the flag is set to true.
Finally, I noticed that you increased the tracking and publishing frequency. Did you see an increase in robustness from these new parameters? Usually, for general environments, I would suggest leaving these as the default values, as you will likely have a better feature triangulation between keyframes. Additionally, enabling feature refinement can also help.
-
@zauberflote1 Hi,
So, it’s almost impossible for OpenVINS’ VIO to successfully reset while the drone is in flight if even a simple hand movement (which I always tried to do gently) is enough to prevent proper reinitialization, right?
What I used to do to break the VIO was cover the camera, wait for x, y, and z to return to zero, and then uncover it.
As for the test environment, it's rich in features, so I don't think that's the issue.
I increased the publish and tracking frequency because I wanted to ensure the VIO was "responsive," and with two or three cameras, I consistently achieved reliable results.
