@cguzikowski , Sorry for the delay. Regarding the new HW not working, since you have two identical setups, i would recommend swapping components to identify what exactly is not working. This is the most efficient way to diagnose it. From the logs you provided, the ov64b camera is detected and initialized, it seems, but no frames come in, which could be a cabling or interposer issue. I will get back to you with an update on the lens shading tomorrow. Alex

@jameskuesel , I think there is another option which i have not considered before. The first three cameras are the same as above: : M0173 J1: AR0144 slot 0 : CCI0 : M0173 J2: AR0144 slot 6 : CCI1 : M0173 J5: AR0144 slot 2 : CCI2 Then if we use J8U (which can be done using M0181 - it allows you to connect a Boson sensor to lower slot, and a tracking / hires camera to upper slot). Then the fourth camera would be: VOXL2 J8: M0181 Upper : AR0144 slot 5 : CCI3 And there are no CCI conflicts. One issue is that we don't typically sell M0181 by itself (only in a kit). Instead you could use two other options, both of which allow connecting a tracking / hires camera to the upper slot: M0194 : https://www.modalai.com/products/m0194/ M0172: https://docs.modalai.com/M0172/ / https://www.modalai.com/products/mdk-m0172-1-00 The only down side of using M0172 / M0194 instead of M0181 is that the two alternatives do not have a mounting hole that would align with VOXL2 mounting hole, but M0181 does have a tab with a mounting hole for VOXL2 J8, see below. The M0172 and M0194 were really designed as mainly options for VOXL2 mini. [image: 1780458131518-98d5f0ec-7f07-44bf-b002-036aefd3921d-image.png] [image: 1780458149322-c9c77086-b5fc-4215-99a2-fdc310d6f18c-image.png]

@Jskim This is the repo we use for support of UVC cameras: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-uvc-server. I don't think it will work directly with Seek cameras but you can try. In my experience each new camera requires a bit of integration work and updates to that code.

One thing that helped me before was comparing the device tree and driver setup against an already supported sensor with similar specs. A tiny mismatch in clocks or I2C config can stop the sensor from initializing properly.

Hi @bschulzhf , voxl-inspect-cam -a command should not be generally used as it puts a lot of stress on the system. just use it to inspect the stream that you need, such as voxl-inspect-cam hires_down_large_color. Also, in your camera config changes, it is not clear exactly what changes you actually made, since you did not provide a diff (but i can see that you probably disabled all the streams except for the preview stream). In any case, you should revert your changes and just inspect the stream you need to estimate the latency. If you want to provide more information about your application, we can suggest appropriate camera server parameter changes. I do see that ae_desired_msv": 60 is potentially too dark (the target average pixel value for auto exposure control) - you can try increasing it and see if the image is too dark. Alex

I tested the fix and snapshots work now, thank you very much!

@Anthony-Kang , we are looking into this. However, initial attempts to enable Intra Refresh on VOXL2 via the OMX api did not succeed either for h264 or h265. Also h265 does not work with fixed Macro Blocks (Coding Tree Units instead), so it seems the OMX structures for this param would not work with h265. Alex

If you're still having trouble getting that single sensor to initialize, double-check that your voxl-camera-server.conf file is strictly set to only enable that specific physical port. Sometimes the server tries to look for the default stereo pair and throws an error if it doesn't find both. It also helps to run voxl-inspect-cam -a just to see if the hardware is even being detected at the system level before diving deeper into the JSON settings.

@SKA , Most of the supported cameras (except for Boson, Hadron) have their reset signal connected to VOXL2, so when the cameras are not in use, they are shut down via the reset pin. This means that the camera modules may still get power, but they are shut down. There are many power rails and interposers - some power rails remain on all the time (5.0, 3.8V) and others may be shut down by PMIC when not in use. Different cameras use different power rails for their operation, so it is hard to answer this question without knowing the specific use case. Alex

Thank you for the quick reply. I will try doing as you instructed and post the results. Thank you. Kim

Hi @Vinny Thank you for your reply! That's good news:) We are looking forward to it!

@SKA , I am not sure. please disable all streams except preview and try again. specifically disable: small_video large_video snapshot Double check to make sure: en_raw_preview: true en_preview: true en_misp : true It seems you have at least small_video enabled. What camera resolution are you requesting? (preview_width, preview_height) Alex

Hi @Alex-Kushleyev, sorry for the late reaction, it took some time before i could update to the new SDK (1.6). the system now works normally with the resolution 2704x1540, and downscaled to 1920x1080 for the MISP pipeline. Thanks for the help!

@yashpatel , Please see some responses below: i2c_geni a84000.i2c / 884000.i2c: i2c error :-107 This is likely due to a service that is enabled for a sensor that's not present, so the service is restarting and trying to detect the sensor. please make sure the voxl-rangefinder-server is not running and also voxl-lepton-server. you can disable the service using systemd : systemctl disable voxl-rangefinder-server. CAM_ERR: CAM-SENSOR: cam_cci_i2c_read: 35 rc = -22 this one is usually present when you have a sensormodule driver in /usr/lib/camera for a camera that is not actually plugged in, so the probe fails. Double check the cameras that you have plugged in vs sensormodules peresent in the directory above. However, this is usually harmless, if all of your cameras are working properly. Pin conflict.. We will double check that, but GPIO 130 is on a Board to Board connector that you are most likely not using, so that should not be an issue. VIO performance.. please review : https://docs.modalai.com/flying-with-vio/ try to identify the condition that caused the low feature count (look at the actual images, if possible). may need some hand-held testing and looking at the output. Please let us know if you have any other questions. Alex

@Alex-Kushleyev sure thing. As per your suggestion, I modified voxl-lepton-server by moving all the Lepton camera-specific logic into a C++ class and added locks to any I2C operations to prevent race conditions. I then just created 2 instances of the LeptonCamera class I made which parse and publish the camera feeds to their own pipes which I can view in voxl-portal. I didn't need to disable any I2C interface for the second Lepton. I'm not too sure what you were referring to by that. In regards to the horizontal line artifacts, those don't seems to consistently appear and I don't know what causes it. I'll investigate it further. My next steps are to get the Leptons working with voxl-open-vins-server. One question I had was that our VOXL 2 Mini appears to be running a service called voxl-lepton-tracker however I cannot find the source code for this anywhere on the voxl public GitLab. Was it removed or hidden?

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

Another question.. did this work for you before or is this the first time trying to calibrate at half resolution? if you request the full resolution, do you get the non-zoomed image? i know it will be slow to display in voxl-portal, but you could still check. If you enable EIS with default camera calibration (no intrinsics cal file). does EIS and zoom work as expected? note that your version of voxl-portal may not have the browser support for zooming, but the config file zoom should still work. If you want to use the latest voxl-portal for EIS, please use this branch : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-portal/-/tree/eis-integration . however the initial zoom of the image coming from the camera server is not dependent on the version of voxl-portal. Alex

@mkriesel You'll need to re-flash the SDK and select the correct kernel option that supports C11. When running ./install.sh you'll see the following options: Would you like to continue with SDK install? 1) Yes, with questions along the way to configure VOXL 2 2) Yes, just update SDK keeping the same SKU configuration 3) No Select, option 1, and you'll get the option to choose which kernel to flash Detected: M0054-1 (QRB5165M) Detected: Config 1 w/ M0173 Breakout Board (Starling 2 Max, Starling 2, FPV V5) ======================================================================================================= In order to support all of VOXL's camera configurations, specific drones require differing kernel images. Please select your drone hardware to proceed with flashing the appropriate kernel image. ======================================================================================================= PLEASE SELECT WHICH KERNEL TO FLASH 0. M0054-1 -> QRB5165M, Starling (D0005), Sentinel (D0006), FPV V4 (D0008), D0010, PX4 Dev Kit (D0011) 1. M0054-1 -> QRB5165M w/ M0173 Camera Breakout Board, Starling 2 Max (D0012), Starling 2 (D0014), FPV V5 (D0008/D0019/D0020) Select your choice from the options above or press [Enter] to continue with current config: For your use case, you'll want to select option 0 as you are not using an M0173 camera breakout board and the C11 camera config is inherited from the sentinel (D0006) platform.