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

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

Hey there, voxl-logger for openvins is only avaiable using a combination of raw flags, e.g. -c tracking_front -i imu_apps -r ov -r ov_extended -r ov_overlay Yes the -o option for odometry is not completed yet for openvins. That hsould get you the log data for openvins

As for simulating camera stream failure, it's very likely any attempt to cover a camera will increase the exposure of that stream, and in some cases you will still see random features: for example, covering with a finger will still pick up features from your finger print. We're still actively improving voxl-feature-tracker and should have a new version available soon.

@Jetson-Nano If using QGC for mission planning, indoor missions are more of an approximation since openstreetmap displays no indoor spaces (e.g. approximating waypoints on the roofline of buildings). If there's a way to overlay an indoor floorplan/raster or add custom maps using a WMS server into QGC would be ideal. Then you can ingest a floor plan of a indoor space and perform precise waypoint planning. Note QGC mission planning provides distance info between waypoints, so one can construct an fairly accurate flight pattern (e.g. for navigating known aisleway & starting point for example).

To describe what's happening under the hood: we're using QGC's takeoff mission item as the local position origin for VIO, and its registered lat-lon is used as a global position offset (though you can manually type it in as well in QGC). From there, waypoints are executed in reference to that origin and true north (of the map). In the end, you're basically flying a pattern based on the take off point and true north. Hence, it doesn't matter where you fly on the map cause this feature is telling PX4 where the drone is located in global space (when running vio only)--and executes the same flight pattern [on the map] from the distances & heading.

Alternatives for indoor "mission planning": we do offer voxl-mapper (trajectory-style) as well as wps mode in voxl-vision-hub (waypoint-style), though both are offboard mode planners in local space and thus precise by setup, but being offboard-mode based, you do not get all the safety measures that PX4 mission mode provides (e.g. RTH, PL, Geofencing, Auto-mode, etc...).

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

Hi there, yes, unfortunately the repo for OpenVINS is still under construction as it's under active development by the ModalAI team. We'll have it available soon

voxl-open-vins-server does a similar process to the ROS implementation when using camera data--in order to sync frames, data comes in a stereo-type packet. During camera calibration, instead of Kalibr, we are using our own voxl-calibrate-camera implementation that comes with the SDK. And as needed, one can turn off the stereo output in voxl-camera-server and calibrate each camera individually. That would be best on the ROS side as well where you can use split the images from camera-server like this before publishing to Kalibr (where 2 topics work best for openvins), then calibrate independently.

You could try voxl-calibrate-camera instead and yes it will output opencv-format intrinsics where you can copy the needed values into the ROS launch file. We create extrinsics using mechanical design. In both cases, OpenVINS will refine them at runtime during the first few seconds of operation.

You can upgrade to the latest dev version via editing your /etc/apt/sources.list.d/modalai.list on voxl2 to point to the dev repo. Then run apt update && apt upgrade voxl-open-vins-server. Looking at the /etc/modalai/voxl-open-server.conf may give you some ideas on how the roslaunch file can be setup as well.

@Jetson-Nano
Hey there, yes, if you are getting the QGC message that the "system is not ready" and will not let you arm in position mode, then you need a patch that sends the correct heartbeat message in PX4 to allow arming. It is in the SDK1.1.1 release, So I believe an apt-get upgrade should solve your problem.

But if needed the code is described here.

Hi all, couple things to clear up on this feature:

With the above parameters you are both setting limits for obstacle avoidance (OA) and collision prevention (CP)--2 different features. Details of each are here: OA and CP

To enable obstacle avoidance, make sure these parameters are being used.

Now collision prevention takes the additional step where you need to set param COM_OBS_AVOID=1. If you get a "Avoidance system not ready" message then that is a know s/w bug that is will be available on our development updates repo shortly. Also note these modes only work when MPC_POS_MODE is 0.

Lastly to disable OA, use these parameters.

Hi there, do you have COM_OBS_AVOID=1 (enabled)? You can set the parameter directly (params) or there's a menu option in QGC.

If so, can you arm the drone? With *_AVOID=1 I suspect all will work as you are seeing obstacle_distance data on mavlink.
If not, then you should get a QGC report "Avoidance system not ready"--let us know which case you end up with.

Hi there, looks like there's some confusion with what mode is being tested. Here's some clarification. PX4 has 2 approaches to handling obstacle distance data:
a. Obstacle Avoidance(OA) feature which stops the aircraft if object detection occurs from the voxl-voa service. This requires CP_* parameters set that you can compare with your drone listed here based on your application.

b. Collision Prevention(CP) feature, which not only includes OA, but also rerouting capability in all autonomous modes (position, alt, mission, offboard) and leverages the same voxl-voa service. This requires not only the CP_* parameters but also requires COM_OBS_AVOID = enable.

If your application requires (a), you can leave com_obs_avoid = disable and OA should work out of the box as is. If your application requires (b), then we have discovered a software bug in the VOA service. And the main reason you get the "collision module not ready", no arm possible. It has been corrected [code here] and binaries will be available in our gitlab daily builds shortly.

@AP123 Hey there. Are you running VOA against a stereo camera pair or via a ToF sensor?

If you run voxl-inspect-points voa_pc_out and see data, then the voxl2 SDK services are good and generating the correct mavlink obstacle distance points to PX4. If not then there's a configuration issue.

If that is good, then you need to make sure PX4 has
MPC_POS_MODE = Simple pos control or smooth pos control, COM_OBS_AVOID is enabled, CP_DIST > 0 (e.g. 2) and you must have an established home position (or good position from qvio if that is the case). Typically an "obstacle system not ready" is due to the MPC_POS_MODE (I think we default to acceleration-based input).

If all those check out, then it's likely missing a home position requirement in PX4 & not voxl, and we'll need to look that up.