Topics created by Kessie

@Kessie Excellent, glad to hear you got it working! And thanks for adding the details on what you had to do to the posting!

@Alex-Kushleyev After updating voxl-portal, it indeed worked.
It is peculiar, because I didn't notice the tracking camera freezing before, only the calibration overlay.
Thanks for the quick support!

@sssagara said in How to tune OpenVins:

I noticed that at all steps, after voxl-reset-vins command is entered, voxl-inspect-vins will always report as STALLED with quality at -1% upon first arming of the drone. This is usually not a problem as the next arm will usually report favourable quality (99%), features (>20) and Z height estimate (at ~0m on ground). However, after the Docker step, I noticed that there was a much higher chance of the Z height exploding in value immediately after the first arming. We're still exploring if the decrease in OpenVINS reliability here is a result of increased CPU usage or other factors

Since SDK 1.4.2 beta 2 seems to work for us (for the most part) as of now, while we try to identify if its a problem on our end, is there a way to prevent apt upgrade from upgrading to the next beta version?

Hi @Cliff-Wong Scratch whatever I learnt in my previous reply. Just did a flight test a day after I conducted those tests

Between my previous successful flight with OpenVINS the day before and today, with environment and lighting conditions remaining the same and the only exception that I bench tested QVIO (by running voxl-configure-open-vins disable and voxl-configure-qvio enable) and then re-enabling OpenVINS again (by voxl-configure-open-vins enable and voxl-configure-qvio disable) and then power cycling, it seemed to have utterly broken OpenVINS

Where in my previous day's successful flight with OpenVINS, upon arming the drone and voxl-inspect-vins momentarily showing OpenVINS has stalled but recovering successfully after disarming and re-arming again, the position estimation by OpenVINS is still valid enough for position hold. However, after switching to QVIO and back to OpenVINS, after the first arming, the Z height immediately explodes and putting it into position hold will just result in the drone shooting to the sky

I'm not sure if disabling the OpenVINS caused some configuration file to change that made it behave this way. This is even after playing around with params such as en_vio_always_on and is_occluded_on_ground for the downwards facing tracking camera.

I tried logging but a bunch of errors came up midway through the logging process. I do have a screen recording of a subsequent flight of QVIO working well and then immediately switching to OpenVINS where it immediately failed. Do let me know who in the team I can send it to privately to have a look at

Thanks

We have managed to solve the transformations and now get the correct tag detection.
But even with fixed_frame_filter_len set to 1, QVIO and OpenVins are used and we see no relocalisation happening.

Does someone have a working example which we can look at, please?

@Kessie Not exactly, but the important data to retain lives in /data/ or /data/modalai

The SDK flash will attempt to retain this partition, but in certain cases it requires a wipe.

I would take note of /data/modalai/sku.txt

as well as pull off any calibration files in /data/modalai, you can see if you have any onboard currently by running voxl-check-calibration

If you have this data saved you'll have no issue getting back to your previous state, I can help guide you through it if you run into any issues.

@Kessie D0012 is Starling 2 Max, voxl-esc setup_D0012 will load the correct firmware for your board as well as the correct params for your drone