Hey @arvind_g3aero So, it does look like you were able to get this working with the dev release of voxl-camera-server which is great to hear. The natural progression of a software package is through dev-> staging -> release. So, this version of voxl-camera-server will be released in a future SDK. There will most likely not be a backport onto the 1.6.2 SDK

ok thanks, I have emailed, please let me know if you have not received it

@royazriel , We do not recommend doing apt upgrade, since we do not test this update method. If you want to update the SDK, you should do that following our SDK install instructions. As an advanced user, you may select to update your apt sources to use dev releases (basically latest dev branches) and selectively install packages that you want to test. The recommended SDK release for Starling 2 (Max) is 1.6.4 With that in mind, please let us know if you have any more questions about this. Alex

And the latest build of our fork with this fix is here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-px4_1.14.0-2.0.146-202607161052_arm64.deb

@RoyAzriel 1.6.4 release is tested on Starling 2 now, go ahead and use that from the link I emailed you.

Hello @royazriel , please take a look at our documentation, which has some testing tips : https://docs.modalai.com/voxl-open-vins-server/

@Eric-Katzfey thanks. before I did sdk reflash I found out the px4 params were somehow corrupted. I have tried to reproduce these values without success. what made it work is taking a similar drawn read the params usign px4-param show -a and writing the to the corrupted one.

@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

@tom said in Latest SDK versions - How to access?: https://storage.googleapis.com/platform-beta-releases/voxl2/voxl2_SDK_1.6.4-beta8.tar.gz Thanks @tom !!!

@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.

@ApoorvThapliyal Thank you for your help. also I was able to work with jazzy by only subscribing and printing with node. since error only occurred when I tried to echo the topic and not when another node is subscribing it. but using docker seems like most viable option to me since I m using ubuntu 24.04. Thank you for your help again

Hi Kim, There are a couple changes required here that will make this work: 1. Rebuilding Kernel with SPI14 enabled You're going to have to rebuild and flash the kernel with QUP14 enabled as SPI. There is also a directional level shifter on GPIO67 that needs to be set to high in order for SPI on QUP 14 to work. I created this branch for you that should have the kernel changes that you need: feature/voxl2-mini-spi-qup14 (link) In order to actually build and flash the kernel please follow the instructions from our public docs on how to build the kernel https://docs.modalai.com/voxl2-kernel-build-guide/ When building the kernel, after syncing but before building, make sure to go to the cloned meta-voxl2-bsp directory and checkout the branch that I created (feature/voxl2-mini-spi-qup14). Also there is a chance you may need to build a kernel variant depending on your device so also make sure to check this document to see if you have a -2 device which would require building the kernel with the -v var02 flag https://docs.modalai.com/m0054-versions/#m0054-1-and-m0054-2 2. Configuring Trustzone with Correct QUP I would recommend using the devcfg binary that comes from the `voxl2-mini_SDK_1.0.0.tar.gz. In order to flash devcfg you'll want to run the following command fastboot flash devcfg <path/to/voxl2-mini_SDK_1.0.0/devcfg>/devcfg.mbn You should flash the kernel and devcfg (Trustzone) during the same fastboot session to avoid running into any issues with the device booting. Let me know if you have any additional questions or run into any issues!

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