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.

@berayksl Hi there,

In the VOXL2 file /etc/modalai/vio_cams.conf all the cameras should be listed as a JSON record. the top-level disable attribute of each record can be edited to turn cameras on and off (make front true and the others false for just the front camera).

On calibration, instructions can be found here.

If the camera's physical positions changed from delivered, then you'll need to update the extrinsics.

@berayksl
Hi there,

1. Since you were able to run a limited bench test, having it fly away after a couple movements indicates 3 possibilities:

• extrinsics are incorrect -- either bad imu_apps to cam# values or camera outputs are flipped.
• intrinsics are incorrect (bad camera calibrations)

2. yes you can run without mag enabled. Should work normally if (of course) VIO is running normally.

3. As for PX4 parameters, VIO enabling can be setup applying this param file.

My thinking is the camera extrinsics maybe off or mismatched to the camera ID. If you can only enabling one camera at a time and run the bench/hand test as if like a single camera vio setup, hopefully it will reveal the misconfigured camera (if all then we have an imu issue).

Hi there, just a quick sanity check. Does the drone fly normal in manual mode?

If so, it is worthwhile to do a hand/bench test by powering up on a flat surface. Then connect to the drone via wifi and startup VOXL-Portal. Going to the VIO panel in portal, if you life the drone up and down, then left and right, it should be reflected in portal with the correct trajectory display. If not and it drifts in manual mode too, then there's like a voxl2 calibration or param issue (not vio).

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