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').

@berayksl Hi there. being 1.4.3, you may want check the parameter in /etc/modalai/voxl-vision-hub.conf that:
"en_vio": true,

Also, on some setups we noticed added latency that triggers the PX4's EV timeout and could explain the "invalid setpoint" log message. In PX4 please set EKF2_NOAID_TOUT parameter in QGC to 8000000.

Checking the above and before your next test flight, perform a hand test as follows:

1. startup voxl portal & connect to the drone (web browser w/ip addr of the drone as the url--wifi must be running)
2. goto the "vio" tab in portal
3. pick up the drone and move it back and forth, then left and right. You should get something close to a "plus" trajectory in the portal screen (see attached). If it "flies away" then good chance calibration (imu, or camera, extrinsics) is off. If it stays frozen/unresponsive then there's a SDK configuration error.
4. If you can repeat what is shown in the image, that confirms VIO is working properly and likely the above NOAID issue..
   
   --
   --

if you're still having issues on take off, then you can modify in /etc/modalai/voxl-open-vins-server.conf and try the blind takeoff option by setting "en_vio_always_on": false, but note VIO will not report any movements (vio position will report as if frozen) until you arm the drone.

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