Posts made by jameskuesel

Currently I'm trying to get the GPS working on the Starling2 along with a custom airframe. After a bunch of experimentation I'm seeing that having specifically the hires camera (M0161) plugged in and running is causing a noticeable degradation in GPS quality. (Higher EPH, takes longer to acquire satellites/fix, etc.) Assumably, this is due to EMI.

Is this something anyone else has noticed with the hires? I’m hypothesizing it is because it is using proportionally more power and transferring more data (compared to the other cameras) that this is occurring/is more noticeable. 

Besides moving the GPS module further away, are there any other techniques or suggestions Modal has for reducing EMI noise? Namely,

1. Shielding

   • Any materials in specific for wrapping cables or blocking EMI, copper, EMI tape, others?
   • Cables to shield, the gps wire? The Hires Coax, the M0161 itself, the camera board, barrier below the gps module, everything?

2. MIPI Clock rates

   • Bit of a long shot (I’m not really familiar with any of this) but I read online that sometimes changing the clock rate can help with EMI. Not sure if this an option, would help, or even possible. Wondering if I could apply this to the Hires. Again, a long shot.
   • https://en.wikipedia.org/wiki/Camera_Serial_Interface

Any advice is much appreciated, thanks!

@Alex-Kushleyev Sorry for the delay got sidetracked with some other things but wanted to close this ticket out.

Focus did indeed seem to be the issue. However, seems like most of our M0161 modules simply did not come with any epoxy, or at the very least not enough to prevent the lens from spinning accidentally. Something to watch out for.

Also, I found that at least on Voxl-SDK-1.4.0 for me it seems

com.qti.tuned.imx412_fpv.bin

is indeed what is being loaded as default. By renaming com.qti.tuned.cmk_imx577.bin to force the camera server to load it I found the picture at least aesthetically more pleasing. But that is obviously subjective.

Anyways, yeah focus seemed to be the major issue.

@Alex-Kushleyev

Hi Alex,

To get the M0161 (COAX) all I did was run the install script, and then selected all the options relating to the starling2 since that is what I was collecting these on.

I've been recording the preview frame (en_preview: true) modified to be at full res (4056x3040), stream via voxl-logger.

voxl-logger --cam hires_color.

I did a similar process for the M0107 (RIBBON), except selecting the first kernel option. Then I modified the custom_camera_config.txt in /data/modalai and just set

J6_LOWER_SENSOR="imx412"
J6_LOWER_NAME="hires"
J6_LOWER_ROTATE="false"

I think you are correct that our Starling M0161 lens is a little bit out of focus. However, we tried with another M0161 module we had around that looked more "in focus" but still had the sharpness issues. The resulting images between the M0107 and M0161 look different enough that I feel it is something more than just the focus but I am unsure.

M0161 but DIFFERENT module (more focused?)

Anyways, yes let me know when you get some sample images and would also love to experiment with the logging of the raw images. Also, how did you set up both modules at the same time? I was trying to figure that out but had no luck.

Hi Alex, Thanks for the reply.

Unfortunately, I didn’t see any improvement with any of the changes you suggested. That being said I was a little confused on some of the setup. 
To reiterate, this was done on a

Starling2 with IMX412 M0161 attached via a coax cable.

After a stock flash of Voxl-SDK-1.4.0, running 

logcat | grep -i tuning

would return com.qti.tuned.imx412_fpv.bin as being loaded. However, your response seemed to imply that com.qti.tuned.cmk_imx577.bin would be loaded after a stock flash. After removing com.qti.tuned.cmk_imx577.bin there seemed to be no change. Logcat still implied com.qti.tuned.imx412_fpv.bin was being loaded. However, I did also try removing com.qti.tuned.imx412_fpv.bin which then indeed resulted in com.qti.tuned.default.bin being loaded. I saw a difference in how bright the image was but not how sharp it looked.

I did another stock flash to reset everything and proceed with running your linking command. That looked same as stock. But as previously mentioned, if com.qti.tuned.imx412_fpv.bin was already being loaded, then linking com.qti.tuned.imx412_fpv.bin would probably look the same, which it did.

I also attempted to force the system to use com.qti.tuned.cmk_imx577.bin by replacing the contents of com.qti.tuned.imx412_fpv.bin with it. This provided an even brighter image, but still no noticeable improvement in sharpness.

I’ve included the pictures here and what driver I THINK was being used. To me it seems that for the Starling2 kernel that maybe com.qti.tuned.cmk_imx577.bin isn’t being loaded by default.

The downsampled images are hard to compare so I included a drive link again.

com.qti.tuned.imx412_fpv.bin (Stock??) VVV

com.qti.tuned.default.bin VVV

com.qti.tuned.cmk_imx577.bin (forced it to use (or at least I think I did))

VVV

Moving on, decided to do some more experimentation which was even more puzzling. We happen to have an

IMX412 M0107 that attaches via a ribbon

module that we attached on J6Lower (with a different breakout board). To achieve this had to do a re-flash and use Kernel #1 (not the Starling2 Kernel as it seems like that one is incompatible). This surprisingly produced great results, much brighter, and much much better sharpness. The difference is night and day compared to the coax M0161. This time, it does seem that com.qti.tuned.cmk_imx577.bin was the one being loaded as you implied might happen after a stock flash.

A little confusing on what exactly is going on here. Obviously they must be using different drivers as this test and our Starling2 test use different ports. (J6Lower vs J6Upper). Furthermore, these experiments required using different kernels.

Should there be this big a difference based on using a coax vs the ribbon (M0161 vs M0107) or is it because of the different kernels? Do you have any sample images from the Starling2 Hires (M0161) with coax so we know what we should be expecting?

What we saw with the ribbon (M0107) is what we are aiming for but with the coax (M0161).

Thanks again for the help, any insight would be much appreciated.

Drive Link (better for comparison in sharpness)
Drive Pictures

Recently I went about upgrading from the

M0024 IMX214

to the

M0161 IMX412
Lens Mount: m12
Lens Part No: 27629F-16MAS-CM.

However, initial tests left us somewhat puzzled. For the imx412 I used the latest VOXL2 platform release with SDK 1.4.0. I saw a significant degradation in quality of the image with the IMX412. For the IMX412 I used the preview frame at the full resolution (4056x3040). For the IMX214 I also used the preview frame but at (4208x3120) Posted below are some samples. I recorded them via voxl-logger

I believe the imx412 has a wider field of view so perhaps some degradation in quality it to be expected as it might have a slightly lower angular resolution? As perhaps fewer pixels are available per degree of FOV? That being said I wouldn't think this much worse. Similarly, the exposure looked much worse. A good target here is the donut box.

Here are two downsampled images since the forum wouldn't let me post the full images. For the full images straight from voxl-logger I included a link to them in google drive folder (granted google might also downsample them but you'll still be able to see the difference. Any help/input on the quality difference would be much appreciated. Not sure if this is to be expected? Maybe something is wrong with the driver?

IMX214

IMX412

[Google Drive link] (https://drive.google.com/drive/folders/1rZV6LM5qSqLjSTxz58Eq4tsZ0AO3cMxz?usp=sharing)

I noticed you can only run the TOF at a rate of 5fps or 15 fps in voxl-camera-server. Is there a specific reason for this. Why not 10fps, for example? Just curious. For my specific application 10 is really all I need.

Hi!

What frame rates does the VOXL2 support with OV9782 cameras? Does it depend on the configuration? Max it seemed I could bump it up to was 30 fps but maybe that was only in my specific configuration (I'll note not one of the officially supported ones!).

Which frame rates are supported and is there a max frame rate? Is there a list I can view somewhere I could view of sensors and supported frame rates? I didn't see fps on the spec sheets.

Also, I am assuming this is how this works but does voxl-qvio-server run at the rate the camera it is using is set to? I know in previous posts it has been mentioned that bumping the fps doesn't make a huge impact. That being said, I did run an AR0144 camera at 60 fps and do I think I saw a bit of an improvement compared to 30. However, the results are a little anecdotal. Observed slightly better quality, num features, and less dropouts in difficult enviroments.

My plan is to run the OV9782 at 60 fps if supported and makes a difference.

Thanks!

@Eric-Katzfey a TOF ranging sensor - VL53L1CB by ST

Hello I am using the libaqp8096 i2c functions https://gitlab.com/voxl-public/voxl-sdk/core-libs/libapq8096-io/-/blob/master/lib/include/voxl_io.h specifically voxl_i2c_read() and voxl_i2c_write(). I am using the voxl read and write functions for reading and writing multiple bytes at a time.

When I print out the read and write buffers, it looks like it properly writes to the buffer but the results from the read buffer are incomplete. For example, if I write uint8_t wrbuffer = 0x1234 to register address 0x0004, it writes 00 04 12 34 (the first two bytes for the address) and reads back 02 34. Another example: I wrote uint8_t wbuffer[4] = {33,55,77,99} and it read back 01 55 77 99.

I noticed this issue happens with a write then read. If I read from a read-only buffer, it reads correctly.