Posts made by Alex Kushleyev

@jimbow77 and @oasisartisan ,

TOF V1 (which is now EOL, so you don't have it on Starling 2 Max) was set up the following way:

• The calibration data was downloaded the first time the sensor was used and stored in /data/misc/camera/, then re-used for next time
• calibration files include pmd.spc, tof_cal_eeprom.bin and irs10x0c_lens.cal - the latter likely containing the intrinsics calibraiton data (although i have not checked explicitly)

TOF V2 (what is shipping in Starling 2 (and Max) ), is set up so that the TOF Library downloads (via i2c) the calibration data each time the voxl-camera-server starts. This is done internally to the TOF libraries. I don't know exactly why there is a difference between how the calib data is handled for two sensors by the TOF software, but this is how our sensor vendor helped us set it up. The TOF processing software downloads the calibration from the sensor each time voxl-camera-server starts and applies it to generate the point cloud. It may be possible to get the TOF intrinsics using the TOF library API, but we have not checked.

Do you have a specific reason why the TOF intrinsics are needed?

If you wanted to calibrate the TOF sensor yourself, then you would either need a checkerboard some material that is IR reflective ("white") and non-reflective ("black"). Alternatively, you could use an array of IR leds (or IR reflective dots + IR light) and use dot pattern detector as opposed for checkerboard for calibration.

Regarding Hi-res cameras, the intrinsics are not calibrated and not included. It can be calibrated using our camera calibration app (voxl-camera-calibration), but you should do it at half resolution or smaller (not full size like 4056x3040), otherwise the app runs very slowly. If you need more details how to calibrate at high resolution, let me know (involves downscaling exactly by a factor of 2 and then upscaling the resulting intrinsics)

Alex

Hi @Haxerus ,

I will double check regarding enabling J10 in spi mode on VOXL2 Mini.

Can you please confirm that you did all 3 changes:

• the DTS changes you listed below
• used the older devcfg.mbn file from SDK 1.0.0
• configure the level shifters to SPI mode using voxl-gpio -w 67 1

Can you please clarify which second i2c channel was used in your test for the 2nd lepton?

Thanks!

Alex

@Dronodev , this is a bypass capacitor 10uF 10V (0402) and it is used for one of the main power rails (digital power supply VDD). You should try to replace it, since without the capacitor, the camera module would be out of spec. You can use a similar capacitor, even rated down to 6.3V or lower (actual voltage is 1.2V on VDD).

Alex

@Haxerus , that's great to hear! Can you clarify what you did? I am guessing the following:

• modify voxl-lepton-server to run multiple instances
• disable i2c interface for the second lepton

Also, the image on the left seems noisy (horizontal lines)? I am not sure what it is, something to check.. (is it always present, what about when only single lepton is running).

Do you need anything else for any next steps?

Alex

@Richa . thanks for the details, got it it.

I will need to test the master / slave mode. Is your plan to have one IMX664 generate the sync signal (master) and the other(s) IMX664 being slaves? or all slaves?

I should be able to give it a quick test this week. The change would involve setting several additional registers in the camera configuration, which would mean a change in the sensormodule driver for the camera. we can figure this out after i verify the functionality.

Alex

@Leo-Allesch , please double check that all your cameras are connected as shown in the diagram on this page : https://docs.modalai.com/voxl2-d0005/ (and double check the pin1 locations for each camera)

Can you provide which cameras are detected by camera server (output of voxl-camera-server -l, just the top part)

Also, please list the complete contents of /usr/lib/camera/

Thanks!

Alex

Hi @Rowan-Dempster ,

We just merged the changes to dev : https://gitlab.com/voxl-public/voxl-sdk/core-libs/libmodal-pipe/-/merge_requests/39.

A new build of the libmodal-pipe library will be added after tonight's nightly build here : http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/ .

Any SDK releases after this will include this support.

Alex

if you need the latest packages (libfc-sensor), you can find them here : http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/

@cbay , I am not an expert at this, but i think it is probably related to a additional .c param file, which our custom drivers use, for example : https://github.com/modalai/px4-firmware/blob/voxl-dev/src/drivers/actuators/voxl_esc/voxl_esc_params.c

You may need to add one.

Alex

@cbay , you can run voxl-px4 in foreground mode : voxl-px4 -d , -d to disable the daemon mode (which is used in systemd service mode).

Then you will get the px4 console. You can use the console to add new params and save them

Alex

@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

@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 own 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)

@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

@Morten-Nissov you have the kernel variant 2.0.2, which works with M0188 and M0195 camera adapters, but not the adapters you are using. Please update your kernel to use 2.0.0, there are details in a recent question here : https://forum.modalai.com/topic/4975/hardware-configuration-for-2-m0014-tracking-1-m0169-pmd-tof-1-m0024-hires/7

Alex

@Sarika-Sharma ,

the screen shot you pasted shows that the second tracking camera has not been found. But above, you mentioned that it is detected. Can you check that?

You can also see which cameras are detected using voxl-camera-server -l to list the cameras and please make sure all 4 cameras are found.

Meanwhile, i wlll test this configuration and get back to you soon.

Alex