Posts made by Alex Kushleyev

@Leo-Allesch ,

It seems the TOF sensor and camera port 2 are not functional. I am assuming that you tried using both M0135 adapters to test port 2? Considering that it was working before, this is likely not a software issue, but a hardware issue, but it is not clear why exactly.

All of your cameras are interchangeable in the camera ports, as long as the camera ports and sensors are working (and the sensormodule drivers are set up correctly).

By default, the port 1 (camera slot 1), is reserved for use in a stereo configuration when used with M0076, like this one : https://docs.modalai.com/voxl2-camera-configs/#c10---front-stereo-only . So it will not work as a generic camera port when used with M0135. The functionality can be re-configured in software (requires a change in the kernel), but we don't have a ready-to-go kernel with just this change (we can revisit this later, if needed).

By the way, you can also test VOXL2 J8. J8 is set up in a similar way as J6, that is the J8L can be used for any camera, but J8U is reserved (by default) for another stereo pair. However, this will allow you to test yet another port just to double check things. The camera slot IDs for J8 are 4 and 5. Please note that the orientation of J8 is rotated compared to J6 and J7. You can see how a TOF sensor is attached to VOXL2 J8 via M0076 adapter : https://docs.modalai.com/voxl2-camera-configs/#cx---two-time-of-flights-tof . M0076 is a single port version of M0135 interposer (only providing the Lower camera port).

So, if you test VOXL2 J8, use the lower camera port 4 (J8L).

Yes, M0040 is EOL, so the replacements are not available. The upgraded version of TOF sensor is here : https://docs.modalai.com/M0169/ , however it has different dimensions and connector requirements. We can discuss this further if needed.

What is your goal? Do you need the original configuration working or are you potentially looking for any updates?

Alex

@Leo-Allesch ,

OK, i understand. So i think the next step is to figure out what exactly is not working: cameras, M0135 interposers or VOXL2.

Since we know that the camera slot 3 hardware and software path seems to be working, you can try plugging in other cameras (hires, TOF) in to that slot:

• power off VOXL2, disconnect tracking camera, disconnect TOF and hires camera
• plug in IMX214 hires camera into tracking camera's slot, the camera flex will be going towards the center of M0135
• power on voxl2 and copy com.qti.sensormodule.imx214_3.bin from /usr/share/modalai/chi-cdk/imx214 to /usr/lib/camera/. You can leave the existing sensormodules in /usr/lib/camera/, no need to delete.
• run voxl-camera-server -l to see if the camera is detected
• repeat the same test for the TOF sensor ( you will need to copy com.qti.sensormodule.irs1645_3.bin camera driver)

Alternatively, if you have another VOXL2, you could do some testing with that, but I am assuming that another VOXL2 is not available.

Alex

@Leo-Allesch , thanks for checking that. I am assuming that the cameras used to work at some point - can you confirm? What happened between the working and non-working state?

Alex

@Leo-Allesch , sorry for the delay.

Based on your previous post, only one camera is detected:

Cam idx: 0, Cam slot: 3, Slave Address: 0x00E2, Sensor Id: 0x7750

(if more cameras were detected, you would see them show up in that list, which is output of voxl-camera-server -l).

This is the tracking camera in camera slot 3 (VOXL2 J7 Upper slot). The slot numbers are also labeled in the diagram https://docs.modalai.com/voxl2-d0005/, specifically you can see 0, 2, 3 labeled on the M0135 interposers that are plugged into VOXL2:

I do see the correct sensormodules in /usr/lib/camera/. (slot 0 for TOF and slot 2 for IMX214).

I suspect that you have the hires camera and TOF module plugged in backwards into the M0135 adapters. The tracking camera (unfortunately?) has a different connector orientation compared to other cameras, but pin1 is correctly marked with a dot (or a number 1) on all connectors.

Your cameras should be connected like in the picture below:

Another look (in the assembly of the drone):

Please double check the connections.

Alex

@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