Topics created by mark

@mark , it looks like your version of voxl sdk has an early version of the imx664 driver (not supporting 2704x1540 resolution.

Are you able to upgrade sdk to 1.5.x or 1.6.x?

Alternatively, i could share the latest camera drivers to use with 1.4.5.

I would also recommend updating voxl-camera-server to the latest, but that would also require updating other packages.. would you consider upgrading the sdk or are you locked to 1.4.5?

Alex

Hi @mark ,

Thank you for the update. We will keep investigating the underlying issue that was a result of that questionable camera.

Meanwhile, if you think that the camera is defective and has no damage, you can fill out an RMA request and send it back for an exchange. I cant really comment on what could be causing this on the camera itself (it would be interesting to try it), but the camera is not serviceable by the user.

https://www.modalai.com/pages/rma

Alex

@mark SDK 1.1.1 and greater is required https://docs.modalai.com/M0107/

@Alex-Kushleyev Hi Alex, awesome! - and that's a good question. We don't know necessarily where the text will be in the image beforehand, so do we have to look for it. On the other hand, looking for text and reading it are two different stages - so we are planning to try a pipeline where we first find text at a lower resolution/lower quality and then process selected crops with more resolution and/or processing. So, in short, debayering only selected parts of the image is something that we are interested in, but we only know what regions to process at runtime, not before we look at the image. If debayering selected regions is possible that's something we are definitely interested in. Thanks!

@blossomrd , this issue is most likely due to incorrect YUV line stride or plane stride for a specific resolution. That is to say, the ISP outputs a YUV image with certain line stride and plane stride (there may be some space between the Y and UV planes in order to align the image data for fast processing in hardware) and voxl-camera-server incorrectly interprets that information about the image layout.

For anyone who is experiencing this issue, please post the exact conditions to reproduce:

version of voxl-camera-server camera type used entire voxl-camera-server.conf config file explain how exactly you are getting the image (what MPA pipe) or viewing via voxl-portal and what resolution

Thanks!

Alex

@modaltb,
Is there any news regarding this issue? Are you able to reproduce this phenomenon?

Hi @mark ,

At this time there's nothing in the config file that can alter the color, but we are attempting to get color tuning going such that we can tweak these settings. Right now it's not something we know how to do quickly (yet!), so please bear with us while we get to this (although it's likely over summer time frame).

It looks like configuration 28 is what you're looking for with the standard 3840x2160. That's the resolution I've tested the 214/377 sensors with.

Regarding voxl-configure-docker-support, I tried and was unable to replicate it causing VOXL not to boot.

voxl-configure-docker-support isn't strictly necessary, it's just a handy tool to apt-install docker-ce from the internet and replace the official docker systemd service with one that we tweaked for VOXL.

I did find that the optional docker-autorun service was not starting on boot, that is now fixed in voxl-docker-support v1.2.5

If you are still seeing voxl-configure-docker-support preventing voxl from booting I can look into it more if you provide a full copy/paste of the output from running that command. Perhaps something is different between our configurations.