How to Enable OpenVINS to Start Feature Tracking on Boot for Full Autonomous Use-Case
-
Hi ModalAI Team,
We’ve been testing OpenVINS on the Starling 2 Max platform and have been exploring configurations to enable feature tracking to begin automatically on boot, before arming or takeoff — as required for a fully autonomous workflow (e.g., auto-takeoff and missions without manual perturbation).
Here’s what we’ve observed so far:
• Setting "en_vio_always_on": true in /etc/modalai/voxl-open-vins-server.conf does allow VIO to remain active, but we still need to manually move or perturb the drone for OpenVINS to initialize and begin feature detection.
• Once initialized, VIO is stable, drift is minimal, and position mode flights are smooth.
• However, after a reboot, features remain at zero until the drone is moved again, regardless of flight mode (position/offboard).
• QVIO, on the other hand, starts tracking properly on boot and after restarts without the need for movement — so the issue seems specific to OpenVINS.
If the "en_vio_always_on" is set to false, the feature tracking never begins and VIO reports 100% quality with 0 features and drops to 1% when armed.Is there an intended configuration or recommended workflow to allow OpenVINS feature tracking to begin immediately at boot, even before takeoff or arming, for use in autonomous missions?
If this is not currently supported, could you clarify whether:
1. The system design intentionally delays initialization until after motion (for safety or stability reasons), or
2. There are known workarounds (e.g., specific takeoff threshold values, init triggers, or pre-arm states) for fully autonomous setups.Appreciate any guidance on how to best configure OpenVINS for this scenario.
Thanks,
Tejas Ram -
Hi ModalAI Team,
We’ve been testing OpenVINS on the Starling 2 Max platform and have been exploring configurations to enable feature tracking to begin automatically on boot, before arming or takeoff — as required for a fully autonomous workflow (e.g., auto-takeoff and missions without manual perturbation).
Here’s what we’ve observed so far:
• Setting "en_vio_always_on": true in /etc/modalai/voxl-open-vins-server.conf does allow VIO to remain active, but we still need to manually move or perturb the drone for OpenVINS to initialize and begin feature detection.
• Once initialized, VIO is stable, drift is minimal, and position mode flights are smooth.
• However, after a reboot, features remain at zero until the drone is moved again, regardless of flight mode (position/offboard).
• QVIO, on the other hand, starts tracking properly on boot and after restarts without the need for movement — so the issue seems specific to OpenVINS.
If the "en_vio_always_on" is set to false, the feature tracking never begins and VIO reports 100% quality with 0 features and drops to 1% when armed.Is there an intended configuration or recommended workflow to allow OpenVINS feature tracking to begin immediately at boot, even before takeoff or arming, for use in autonomous missions?
If this is not currently supported, could you clarify whether:
1. The system design intentionally delays initialization until after motion (for safety or stability reasons), or
2. There are known workarounds (e.g., specific takeoff threshold values, init triggers, or pre-arm states) for fully autonomous setups.Appreciate any guidance on how to best configure OpenVINS for this scenario.
Thanks,
Tejas Ram@wilkinsaf Do you happen to have any experience with this?
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login