@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

@Morten-Nissov ,

Is it just the specific camera (tracking) not working in a specific port? what if you connect TOF or IMX214 camera there?

For your configuration using the M0135 interposer, kernel variant 2.0.0 is the correct one to use. Using kernel 2.0.2 will result in some cameras not working due to different pins used for camera reset (which get properly routed in M0188 and M0195 camera adapter boards for the coax cameras).

So i would suggest using the correct kernel 2.0.0, then test one camera at a time and see if you can narrow it down to a camera or port not working.

Alex

@Sarika-Sharma ,

We discussed this internally and we will make an effort to formalize enabling the instructions (in a script) in the near future, but there is a relatively short way of enabling TCP/IP communication between VOXL2 and a QGC host. Please try these instructions and let us know if that works for you or what issue you run in to.

Basically, there is a command to enable the usb gadget in the kernel and this creates the network interface which you then have to configure on both sides. You can change the IP range if necessary.

Alex

# VOXL2 Setup
# Begin by configuring the usb gadget
sed -i '/ln -s functions\/ffs.adb configs\/c.1\/f2/a \ ln -s functions\/ncm.0 configs\/c.1\/f3 2>\/dev\/null | true' /sbin/usb/compositions/901D

# Next setup a udev rule to give our NCM device a static IP (192.168.7.2)
echo 'ACTION=="add", SUBSYSTEM=="net", KERNEL=="usb0", RUN+="/bin/sh -c '"'"'sleep 2; /sbin/ifconfig usb0 192.168.7.2 netmask 255.255.255.0 up'"'"'"' > /etc/udev/rules.d/80-usb-ncm.rules

# Reboot VOXL2

# Check usb0 network device
voxl2:/$ ifconfig usb0
usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.7.2  netmask 255.255.255.0  broadcast 192.168.7.255
        inet6 fe80::935f:1a09:ab1d:d2fb  prefixlen 64  scopeid 0x20<link>
        ether 56:77:2d:6c:84:9b  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


# Host Side Configuration
- note that a network manager may rename the device from usb0 to something else..

ifconfig usb0
usb0: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether fa:74:5a:f3:2b:88  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

#bring up the interface and set it to static ip
sudo ip addr add 192.168.7.1/24 dev usb0 
sudo ip link set usb0 up

# Can also use Network manager to configure the network interface for a static configuration
- address 192.168.7.1
- netmask 255.255.255.0
- gateway 192.168.7.1

# ping VOXL2 from linux host
- ping 192.168.7.2

#set up QGC
- use ip address:port : 192.168.7.2:14550

You can also use other network tools like ssh, etc, to communicate to the host, but this setup does not enable you to communicate from VOXL2 to outside world (using NAT to enable internet access via the host)

@Sarika-Sharma It's not something we currently support

@svempati said in No detections when running custom YOLOv8 model on voxl-tflite-server:

WARNING: Unknown model type provided! Defaulting post-process to object detection.

@svempati I will try recreating this issue today and get back to you!