@cbay That driver is not part of the build nor has it ever been tested on VOXL 2. You would have to add it to the build (e.g. in https://github.com/modalai/px4-firmware/blob/voxl-dev/boards/modalai/voxl2-slpi/default.px4board)

@taiwohazeez This is what most people use: https://qgroundcontrol.com/

@jakkkkobo , It looks correct to me: https://storage.googleapis.com/modalai_public/modal_drawings/M0172_REVA_3D_2025-11-03.step

What is the issue that you see?

@Sarika-Sharma ,

If you have multiple active network interfaces, then you need to set up routing rules using standard linux network tools (ip route ..). You can check the current routes using ip route list on voxl2.

voxl-my-ip script probably just returns the first available ip address. you can use ifconfig to check all the interfaces.

As an example... assuming your wifi ip range is 192.168.10.x (192.168.10.1 is the wifi router's ip address) and usb0 is 192.168.7.x

# route to the Linux host (192.168.7. subnet) via usb0
sudo ip route add 192.168.7.0/24 via 192.168.7.1 dev usb0

# default route for all other traffic via wlan0
sudo ip route add default via 192.168.10.1 dev wlan0

If you want to make these routes persistent you will have to edit /etc/network/interfaces.. Please check Linux networking documentation.

Alex

@Dronodev

Can you confirm you have the raw feed button? Please give a try if you have.

Example follows:

@ggangmi What was the flight mode on takeoff and what did it unexpectedly change to? There should be logs in /data/px4/log. They may be incomplete or maybe even corrupted if the drone lost power in the crash but there should be something there. The logging starts when the drone is armed.

@Nitin-Varma-Vegesna If you re-install or update your SDK to the latest it will properly set all of the parameters.

@Sarika-Sharma ,

Since you are testing different configurations, i would suggest to reduce the number of cameras first to find working cases and see if you may have a bad camera or a bad flex cable.

So, try both tracking camera one at a time, then hires camera by itself, then two tracking cameras, then two tracking + hires, etc..

Alex

@Jetson-Nano ,

We have not tried QVIO with Boson, it may work (but we can't really support that). The boson output is usually a bit fuzzy, so i am not sure how the feature detection will work, but it may be ok. Disabling FFC will definitely resolve the gaps in the frame feed, but disabling the FFC will also affect the Boson image quality, which may degrade over time.

If you wanted to use any USB (thermal) camera with VIO, you would just have to use voxl-uvc-server to publish the images to mpa, so that voxl-qvio-server can subscribe to them. The only issue is that the uvc interface does not provide accurate timestamp of the camera, but it may be ok just to use the time of arrival of the frame. QVIO does estimate the time offset between the IMU and camera, so as long as the timestamp is consistently captured, it should be ok..

Alex

@Richa

The IMX664 camera does have a sync input, but we are currently not enabling it in the camera driver.

The sync signal is typically driven by VOXL2 in majority of our use cases and we currently only synchronize the tracking cameras (AR0144).

If IMX664 outputs a sync signal while voxl2 is also outputting that signal, there would be a gpio contention. It is possible to disable voxl2 sync line so that it is not driven.

If you had your own adapter board (or M0173 ?) and wanted to use two IMX664 cameras in master / slave mode, assuming no contention on the sync line, there would need to be some modifications in the camera driver (they could be trivial, but we have not tested it yet on IMX664, but can look into it).

Can you please describe your use case a bit more (specifically, are you going to use our adapter, like M0173) or designing your won adapter that will connect the cameras to VOXL2?

Alex