How to tune OpenVins

Kessie

We are testing with the new SDK1.14 and the OpenVins implementation.
The basic test that we're doing is taking off to 1m and staying there.
What we did see is that out of 50 tests that we did, only 10 were relatively correct. The other ones where going a lot higher.

Hereby 2 flight logs that you can check :
Bad flight : https://review.px4.io/plot_app?log=5e809b1e-3473-425c-8d42-9dce0472b1ef
Good flight :https://review.px4.io/plot_app?log=9fdb3a61-3e4d-4eb2-9b35-10072e665f28

How can we tune the performance and accuracy of indoor flights?
Can we get some technical help on this, please?

Cliff Wong

@Kessie Hi there, can you please post your vio_cams.conf file?

So far is appears the Quality of the vio data is degrading in both flights, just faster in the bad flight. Is there a reason to sit in the takeoff state (on ground, motors spinning) for 20+ seconds? A scenario like that will create a level of vibration/movement in the cameras where ovins will start to pick up false positive features creating instability. We can increase the threshold for takeoff, but may give an undesirable offset of a origin (0,0,0 maybe 1/2m above the ground for example). You can first try increasing the following values by 50% increments:
"zupt_max_velocity": 0.03,
"zupt_noise_multiplier": 1,

Hence:
"zupt_max_velocity": 0.045,
"zupt_noise_multiplier": 1.5,

And see if that improves.

Kessie

@Cliff-Wong sure, it is the default for Starling 2 Max:
{
"cams": [{
"enable": true,
"name": "tracking_front",
"pipe_for_preview": "tracking_front",
"pipe_for_tracking": "tracking_front_misp_norm",
"is_occluded_on_ground": false,
"imu": "imu_apps",
"cal_file": "opencv_tracking_front_intrinsics.yml"
},{
"enable": true,
"name": "tracking_down",
"pipe_for_preview": "tracking_down",
"pipe_for_tracking": "tracking_down_misp_norm",
"is_occluded_on_ground": true,
"imu": "imu_apps",
"cal_file": "opencv_tracking_down_intrinsics.yml"
}]
}

We've also tried to only use the front-tracking camera, but with a same result.

The longer waiting time was because we were checking the number of keypoints and the 6DoF result in ov_overlay before taking off. (Hoping to identify what is the culprit)
We will try tuning the mentioned parameters

Kessie

@Cliff-Wong We have tested further, but we keep getting drift on the Z-axis.
There are moments that it works OK-ish, but the majority of our tests, the height estimates starts to go down (value goes up) and we have no clue about the reason.
FYI : We are testing this in a warehouse with plenty of good features and consistent lighting.

Cliff Wong

@Kessie

Again, longer waiting times on the ground during pre-flight (<2min) will introduce drift either by thermal issues or feature noise.

To address thermal issues, the IMU is not temperature calibrated from the factory. You can do so by running
voxl-calibrate-imu-temp

To address feature noise, you can raise the drone a couple inches above the ground (typically 3 inches).

If both cases cannot be done in your application, we do offer a blind takeoff feature in ovins, by setting in voxl-open-vins-sever.conf:
"en_vio_always_on": false
But note, you will see vio stay 0,0,0 (even if you move the drone) and see any feature points freeze in place as this feature holds the vio state at 0,0,0 until the drone is armed and very slow takeoffs can introduce a static Z offset upto 0.1m.