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
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
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
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
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!
@Pelle-Bredegg-Hermansen
Hi Pelle,
I emailed you the schematic review report for your considerations, just wanted to post here this task is completed.
Keep us posted!
Thanks!
Hi @Richa
We have not provided our pinouts for this and have no plans to.
For our Micro Coax direct CMOS based sensors, you need to use our products end-to-end to guarantee functionality.
Hope this helps clarify.
@cbay , you could actually test two leptons by disabling i2c port for one (or both) of them. Lepton starts up streaming data by default via SPI, so you can get frames from it without any communication.
In order to do that, you would need to run two instances of voxl-lepton-server and the second instance would have to be modified to read from a different config file and to not kill the existing voxl-lepton-server process (and probably name itself differently, so that the first server does not kill the second during start-up).
If this all works, then in order to actually test two leptons with i2c communication (which we use the set the FFC mode depending on the flight mode and also reset the sensor if it gets into a weird state while streaming), the lepton server functionality would probably need to be added to a C++ class so that multiple instances could be run from the same process. The reason is that there needs to be a single point where the i2c switcher is set to one or the other lepton, right before communicating to one of the leptons (without the other server / thread creating a race condition and trying to do communicate right at the same time)..
I'd have to think about the fastest way of doing this, but at least you should be able to test two leptons with second not using i2c with very minimal changes.
Here is the source code for the voxl-lepton-server in case you did not already find it: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-lepton-server/-/blob/master/src/
Alex
