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.

@Jetson-Nano Hi there, here's a tutorial on using this feature.

The video applies one of the vins_vio params-- based on if you are planning indoor or outdoor missions in QGC. The drone will automatically acquire heading from the internal compass. Note, the compass is not used for position estimation, just to acquire vehicle heading at power up. This is required in order to assign a global heading "at origin" (aka takeoff) since we are dealing with QGC's global Lat Lon system for mission planning. This allows a saved QGC-GPS mission be reused as long as a takeoff position is added....and loaded and executable under vio-only position estimation of course.

As an alternative, one may not use the above params, but instead use the option of manually entering in the heading of the vehicle. That is done in the takeoff item's heading field of a QGC mission. That is to allow manually heading change on the fly.

@berayksl Hi there, to address your questions:

• The inconsistent VIO performance between flights

appears the inconsistent vio behavior on multiple arm/disarms is due to the way voxl-open-vins-server re-initializes after a disarm event. Are you still using in the voxl-open-vins-server.conf option "en_vio_always_on": false and "en_auto_reset": true?

If so, the next thing that can be an issue is takeoff speed. To ensure VIO has the correct origin (0,0,0) we have a conf parameter called: "takeoff_accel_threshold": 0.5, This is essential a takeoff detector and is set for a aggressive take off (>80% throttle)

If you are taking off very slow and gentle, it's possible the detector is not being tripped. Try lowering it from 0.5 to 0.3.

• The “Yaw estimate error” message (should I be concerned if QGC shows no error)?

If the error doesn't repeat, it's just VIO telling PX4 to reset it's heading and PX4 complains on reset. This can be ignored. BUT if QGC keeps repeating the announcement, you have a PX4 yaw_gate issue--make sure in PX4 the param EKF2_EV_CTRL has the 'yaw' option checked.

And as a sanity check cause you are seeing an R/C issue: goto the radio tab in QGC and confirm your pitch/roll/yaw inputs are calibrated and centered such that you are not sending biased commands.

• The drone ignoring RC inputs during the second flight

Are you getting a r/c "manual control lost" announcement in QGC or just lack of control when trying to move the drone? On the former case we have notice users in environments with lots of metal (e.g. warehouse) will have RF interference issues.

At this point, we have numerous improvements in SDK 1.5.0 for Max and it maybe worth the upgrade if your system design allows it. It has improvements with the vio-always-on issues, vio resets, and some PX4 altitude improvements.

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