@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

@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

@Cliff-Wong Hi Cliff, thanks for your reply

We have since upgraded to SDK 1.4.2 beta 2. However, before that, in an effort to understand if the problem is a result of bugs in OpenVINS from an outdated SDK version or our algo (that is in docker containers) somehow messing up the odometry (whether by CPU usage or otherwise), I did a clean install to 1.4.0 before slowly installing other packages in steps and testing its ability to position hold using OpenVINS after each step

The steps along the way are:

• SDK 1.4.0 clean install
• Upgrading to SDK 1.4.2 beta 2
• Installed ROS Melodic
• Installed Docker with 2 running containers
• Installed and run MAVROS

Some params that might affect the position hold reliability are fixed as such:

• EKF2_HGT_REF: Vision
• EKF2_RNG_CTRL: Enabled (Conditional)
• en_vio_always_on: true
• en_ext_feature_tracker: false
• Well-lit lab environment

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?

On a side note, regarding voxl-logger, I tried logging and replaying using voxl-logger. But I can't seem to playback the log (refer to below pic) as it seems like the command is appending an unnecessary '/'. Is this a bug or am I doing something wrong here?

@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

@Alex-Kushleyev Hi Alex! Thanks for your reply! I managed to get a hold of a replacement capacitor and it works now! I used a piece of kapton tape to cover the base of the board to prevent any components from getting snagged in the future. Maybe future iterations of the ESC can include something as a simple covering for it

Hi! After not using my Starling2 for about a week, I noticed that I'm unable to power on the drone. After some troubleshooting, I've narrowed down the problem to a capacitor that seems to have knocked off sometime between my previous successful flight and now (pictures as attached). While I'm waiting for a new ESC to be ordered, can anything be done to it that will allow me to at least do bench testing? Or is the ESC absolutely toasted? The LEDs on the ESCs do not turn on and neither do the motors beep. But it still outputs 1.2V instead of the 5V at the main regulator output

Thanks!