Hi there, Yes, let's check the camera stream:

on your host computer, in a terminal, run: "xhost +"

power up rb5, ssh login: "ssh root@10.8.0.x -X" (make sure you have the -X option)
In the rb5 ssh session, run the following:

systemctl stop rb5-streamer   

Then run in the ssh session:

gst-launch-1.0 -v qtiqmmfsrc video_0::bitrate=100000 camera=3 ! video/x-raw,format=NV12,width=640,height=480,framerate=15/1 ! videoconvert ! xvimagesink 

If you get no video, then we have a camera/streamer issue (unlikely). Power cycle and confirm again that there's no video.

But If you get video, then disable rb5-streamer via:

rb5-streamer-configure (choose '2')

power cycle rb5, again, ssh back in and manually run the streamer via:

rb5-streamer -d -c 3

and try to connect via vlc/qgc, the debug output will show a connection of 1 when connected. If not, then there should be output on the issues, If there is no debug output (and stays '0') then there is a network restriction (e.g. bandwidth is too little) issue. Re enable the streamer by running rb5-streamer-configure (choose '1').

@tkddnjs825 Hello, can you post the output from the command voxl-version. We urge all starling users to migrate to SDK 1.4.1.

@SKA Yes, VFT is actually deprecated in 1.4.1

Please replace your ovins config with this and give it a try:

@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.

@star123 At this time masks are supported through programmatic means only.

I'll add it to our feature list for the next release and should be in our nightly builds by mid-next week. If you take a look at /data/modalai/zero_ref.jpg is an example format to give you an idea when the feature is ready.

@SKA Can you post your output from running on the drone:
voxl-version?
As well as what aircraft model is this? (appears to be Sentinel?)

Older versions (pre Jan 2025) we may need to have yo run the ovins internal-mode tracker. Otherwise it maybe worth to upgrade to the latest SDK.

@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.

Hi there, typically when OVINS is resetting constantly, that means there's no image stream or feature data being sent to it. Since we see a video the image stream is ok.
You want to run in a adb shell:
a. cat /etc/modalai/voxl-open-vins-server.conf and confirm en_ext_feature_tracker: true
b. run voxl-inspect-services and ensure voxl-feature-tracker is running. You can also check voxl-portal and confirm a feature_overlay video feed is present.
c. then restart voxl-open-vins-server -d as you did above.
The drone should be on a level surface when ovins is initializing.

If that doesn't work, can you post your /etc/modalai/vio_cams.conf.

@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.

@Allen-Wu Yes, there are multiple ways to use GPS hardware and data all controlled by PX4. Let me walk you through the possibilities in the order of coarse grain control to fine grain control below:

1. Unplugging the connector to the GPS unit: this will outright disable its capability (also losing magnetometer as well). In this case no gps data will be present in the system nor logged. This applies from power up to power down.

2. Disabling the GPS driver, done by using the PX4Shell and running "gps stop': GPS hardware is still running but data is not used by PX4 subsystems, hence why you still get raw data logged. You can access the PX4Shell via QGC-->[Analyze Tools]-->[MAVlink Console] (type 'help' will show you the command options). This is the scenario in the above video example.

3. Enable/Disable GPS processing: apply PX4 params.
   Apply params using these parameters will include GPS data in the position estimate along with VIO.

4. Removing GPS data in flight: you can just alter these 2 values to add/remove GPS data in the position estimate.
   EKF2_EV_CTRL
   EKF2_GPS_CTRL
   I'll refer to the QGC/PX4 docs on their function. note altering these in flight can cause jumps in the position estimate causing the drone to have aggressive, unpredictable motions until the position is reestablished.

From your request, it sounds like you want both VIO and GPS running, hence you can just apply option #3 until you're ready to turn off GPS.

Hi there, if you're using GPS+mag+vio then you'll need the following PX4 params changes in addition to our vio_gps_baro.params helper file:

EKF2_MAG_TYPE = automatic (voxl default)
EKF2_MAG_CHECK = 1 [or 2/3 for more sensitivity] (voxl default is 0)

Having mag_check = 1 will activate EKF2's field strength checker such that as you proceed indoors should stop mag fusion completely when the field strength goes outside thresholds (hardcoded within PX4 ~ .4gauss variance). It's similar to GPS's DOP threshold where we expect both (gps and mag) to exceed the thresholds where PX4 will stop fusion of those modalities and eventually use vio solely.

PX4's logic tries to maintain "smooth flight", so expect some delay/drift as it starts turning on/off the above (i.e. it will not be instant). Hence, adjust performance in those transitions, you'll need to modify ekf2's baro, gps, and mag *_GATE params accordingly.

Note PX4 will adopt whatever heading is being derived from the activated sensors (GPS/Mag/vio) to construction its "global frame", so proceeding indoors you will still be operating under a global frame coordinate system (will still have a north reference based on last good mag/gps check).