@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.

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!

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?