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.

[sssagara]

@Kessie Seconding this. We have a triple tracking Starling 2. Initially, when on SDK 1.3.5, QVIO was barely sufficient for ensure stable flight without drift in conditions that were a bit too bright or dark. We upgraded to SDK 1.4.0 to use OpenVINS and had better luck in our lab, with the quality and features metric as reference that it will have accurate positioning estimates. But as soon as we brought it out to a different test area that is well lit with artificial lighting, it seems like OpenVINS momentarily stalls as soon as the drone is armed (see below pic). Even after letting OpenVINS recover, the height will drift very drastically even when the drone is still on the ground (see below pic). We tried a combination of single, double and triple camera setup. en_vio_always_on doesnt seem to make a difference regardless if its true or false. When we do have to leave the drone on the ground, we manage the temperature by having a dedicated fan pointed at the processor until it is ready to fly.

For now, we have resorted to going back to a single camera QVIO setup

[Cliff Wong]

@sssagara HI there, the default feature tracking settings have changed since 1.3.5 as we have found performance degradtion in challenging light conditions. I suggest 2 choices:

• in voxl-open-vins-server.conf set en_ext_feature_tracker to false (which will increase cpuload may affect your/3rd party applications, ros, etc...)
  or
• we urge upgrade to SDK 1.4.1 with its improved feature tracker configuration that will correct these take off issues (preferred)

We have noticed that sitting unarmed before takeoff, if there are no features (< 3) or features jumping around (3 <-> 12+) when one arms the motors for takeoff: that will cause ovins to drift off due to lack of features (dead reckoning). If you can run a screen record of voxl-portal's ov_overlay screen or run voxl-logger -o and post that log we can confirm that is your issue and can provide necessary steps to correct.