OK, some updates..

the reason why the resolution 9216x6944 was not accepted for snapshot is that the camera pipeline has a list of allowed resolutions and that resolution was not one of them. I could add the resolution 9216x6944 to the list, but actually another resolution (9216x6912) was already supported, so i updated the ov64b driver to include that. The latest driver is available here : https://storage.googleapis.com/modalai_public/temp/ov64b/20260417/ov64b_20260417.zip

this driver has the following resolutions : 9248x6944, 9216x6944 9216x6912 and the other lower resolutions. You can use 9216x6912 since it's compatible with misp and isp snapshot.

I also added 9216x6912 resolution to the supported misp resolutions in camera server (dev branch) as well as allowed using misp with snapshot (previously it would throw an error since we thought that previously they were not compatible).

Actually, snapshot does work with raw_preview + misp, but here is a warning that gets printed continuously:

WARNING: preview buffer pool for Cam(hires), Frame(30) has 0 free, skipping request

we can work around this warning by adding the following line to the voxl-camera-server.conf for the ov64b camera. this limits the number of buffers that are queued up for the streams and resolves the warning.

"max_request_queue_depth": 6,

So with these changes, you should be able to use two configurations

preview + raw_preview + misp + snapshot small_video + snapshot

Please use the latest camera server from dev branch.

Right now, if you enable misp + small+video + snapshot, it does not work properly, but i will try it figure it out. Here is an example set up for small video + snapshot, but you can easily change it to use misp by disabling small_video and enabling preview + misp (and set auto exposure to "auto" from "isp" (auto will use misp auto exposure)).

Please try it out. I do agree that the ISP output has better overall image quality than MISP, also related to pretty significant lens shading of this small lens on ov64b. We will work on improvements of misp image processing.

For now, you just need to decide whether you need both RAW bayer and ISP JPG, in which case you cannot use small_video for streaming (until i resolve the issue). This means slightly worse image quality for live streaming. But if you are ok with ISP jpg, you can disable misp and use small_video stream for streaming.

By the way, i did not see any artifacts in the jpeg from ISP. Can you please let me know if the artifact is in every frame and where exactly it is located? or is the occurrence and location random?

{ "type": "ov64b", "name": "hires", "enabled": true, "camera_id": 1, "fps": 30, "en_preview": false, "en_misp": false, "max_request_queue_depth": 6, "preview_width": 9216, "preview_height": 6912, "en_raw_preview": true, "en_small_video": true, "en_large_video": false, "en_snapshot": true, "ae_mode": "isp", "gain_min": 100, "gain_max": 1600, "misp_width": 1600, "misp_height": 1200, "misp_venc_enable": false, "misp_venc_mode": "h265", "misp_venc_br_ctrl": "cqp", "misp_venc_Qfixed": 38, "misp_venc_Qmin": 15, "misp_venc_Qmax": 50, "misp_venc_nPframes": 29, "misp_venc_mbps": 30, "misp_venc_osd": false, "misp_awb": "auto", "misp_gamma": 1, "misp_zoom": 1, "ae_desired_msv": 110, "exposure_min_us": 20, "exposure_max_us": 33000, "exposure_soft_min_us": 5000, "ae_filter_alpha": 0.6, "ae_ignore_fraction": 0.2, "ae_slope": 0.05, "ae_exposure_period": 1, "ae_gain_period": 1, "small_video_width": 1600, "small_video_height": 1200, "small_venc_mode": "h264", "small_venc_br_ctrl": "cqp", "small_venc_Qfixed": 30, "small_venc_Qmin": 15, "small_venc_Qmax": 40, "small_venc_nPframes": 9, "small_venc_mbps": 2, "en_snapshot_width": 9216, "en_snapshot_height": 6912, "exif_focal_length": 3.1, "exif_focal_length_in_35mm_format": 17, "exif_fnumber": 1.24, "snapshot_jpeg_quality": 75 }

@boron Please submit an RMA, https://modalai.com/rma and just refer to this thread. Include your shipping information and we'll send you a new one

@RyanH , from the spin log above, i can only tell that the motor attempts to spin up but re-starts after the open-loop sinusoidal spinup is done and the ESC detects that the motor is not spinning.

You should try to clear the debris by spinning the motor by hand first (or use compressed air) and then use the test script to spin for longer periods of time without propeller (changing speeds, etc).

You could use a spin step command to automate increasing and decreasing spin speed (without rpm control, since it's not needed):

./voxl-esc-spin-step.py --id 0 --step-delay 2.5 --step-frequency 1 --power 20 --step-amplitude 30

Alex

@Alex-Kushleyev Thanks so much, we have the resistors on the way, will let you know how this goes.

Once this has been done, I would assume we would have no issues getting all of the cameras working with OpenVins

@Aniruddha
On QGC, do the Parameters ever fully load? The reason I am asking is because if the connection to the GCS is not fast enough or strong enough for QGC to fully download the parameters then the other tabs like sensors and actuators in QGC will not appear. Which is why you are having an issue doing the level horizon from QGC. I know that QGC is seeing the video feed meaning you are connected, is the Green bar going across the full length of the fly view bar on QGC?

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

Thank you.
Kim

@rddrone , you are absolutely right, the snapshot feature was broken. We somehow missed it.

I just fixed it :

https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/commit/6e02fdf2fe6a893b1c9e102a346050dece3e1a7d

and removed references to old buffer groups

https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/commit/b84e10c326ad5abd4077c71f28c6d6a4522cc8a0

Please try it out!

Alex

@Jesus-Cardenas Flat builds should be available now!!

OK @Daehan-Won
Yeah, I'd try to run one first on it's own before the hub to rule that out.
Keep us posted.
Thanks!

@Eric-Katzfey Thank you for reply!

I will try creating a custom build using the document you provided.

I have uploaded the latest ar0144 drivers with fsin versions for all camera slots here : https://storage.googleapis.com/modalai_public/temp/ar0144/ar0144_drivers_20260402.zip

There are two additional files (inside the zip), which you should copy to /usr/lib/camera to make sure you have the latest updates:

com.qti.sensor.ar0144.so -- contains functions for exposure / gain control (we recently made some improvements to make gain control smoother) com.qti.tuned.default.bin -- fixed gain scaling so that min gain (1.0x analog gain) is equal to 100 in the HAL3 gain units, not 54 (and the max gain will be 29.6 = 29600 for AR0144) -- you can also double check this using voxl-camera-server -l and update the min/max gain settings in your voxl-camera-server.conf to make sure you are using the full range.

My colleague will follow up with a diagram for locations of the DNI resistors that need to be installed to enable sync signal for camera slots 1 and 3 (0402 0-ohm resistor)

Alex

@Alex-Kushleyev Hi Alex,

Thank you for the clarification.

That makes sense regarding the accel parsing—agreed that a 4 LSB discrepancy on a 20-bit value is negligible compared to in-flight noise, but it’s good to see it will be corrected.

Appreciate you taking the time to investigate and confirm.
Igor

Hi @irw
Can you please post High Res and clear photos of both sides of the VOXL 2?

@ZuraNeb Perfect! Thank you!

@Alex-Kushleyev Awesome Thank you!

@yaoyuh, sorry for the delay. It looks like we have the lenses in stock, so you could fill out the contract form for a custom order and mention part number "M10000513 - Lens for M0161 Camera without IR filter".

https://www.modalai.com/pages/contact-us

Also, you can remove the IR filter from your current lenses. You have to be a bit careful so that the pieces of filter are not spread in your work space. My suggestion would be to first place a small piece of tape on top of the filter which will keep all the pieces together if the filter breaks during removal. The filter has a rectangular shape and is attached to the back side of the lens with an adhesive in 4 corners. It should be possible to just pry it off from the back of the lens (after completely removing the lens from the camera module). When you remove the lens from the camera module, you should cover it up so that dust does not get inside and on the sensor itself.

Please note that removing the filter from the lens is not an official guideline, but you could do it at your own risk.

Please see the following post where we also discussed removing the IR filter from AR0144 (which was actually more difficult because the filter there has a round shape) : https://forum.modalai.com/topic/4826/msu-m0149-1-ir-filter

Alex

@Alex-Kushleyev, thank you for your answer.
I confirm your assumption, when I set the decimator to 1, the fps is not divided.
Here are the tests I did on SDK 1.5.0 and SDK 1.6.3 :

test with SDK 1.5.0 ; fps = 10 | standy_enabled = false or true | decimator = 5 | Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format | tof_depth | 43200 | 180 | 240 | 2.90 | 0 | 1540 | 28.0 | 10.0 | 3.5 | RAW8 timestamp(ms)| w | h | Zmax | center point (m) (conf) 7170622 | 240 | 180 | 7.1 | -0.0 0.0 0.0 0 fps = 60 | standy_enabled = false or true | decimator = 5 | Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format | tof_depth | 43200 | 180 | 240 | 1.30 | 0 | 2155 | 9.3 | 59.9 | 20.7 | RAW8 timestamp(ms)| w | h | Zmax | center point (m) (conf) 10666991 | 240 | 180 | 3.1 | 0.0 0.0 0.0 0 fps = 60 | standy_enabled = false or true | decimator = 5 | Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format | tof_depth | 43200 | 180 | 240 | 1.18 | 0 | 869 | 9.4 | 59.9 | 20.7 | RAW8 timestamp(ms)| w | h | Zmax | center point (m) (conf) 10753813 | 240 | 180 | 3.1 | 0.0 0.0 0.0 0 test with SDK 1.6.3 fps = 10 | standy_enabled = true or false | decimator = 1 | Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format | tof_depth | 43200 | 180 | 240 | 3.02 | 0 | 260 | 29.7 | 10.0 | 3.5 | RAW8 timestamp(ms)| w | h | Zmax | center point (m) (conf) 2052194 | 240 | 180 | 7.1 | -0.0 0.0 0.0 0 fps = 60 | standy_enabled = true or false | decimator = 1 | Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format | tof_depth | 43200 | 180 | 240 | 1.18 | 0 | 7532 | 9.3 | 59.9 | 20.7 | RAW8 timestamp(ms)| w | h | Zmax | center point (m) (conf) 2190721 | 240 | 180 | 3.1 | 0.0 0.0 0.0 0 fps = 60 | standy_enabled = true or false | decimator = 10 | Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format | tof_depth | 43200 | 180 | 240 | 1.20 | 0 | 83 | 10.1 | 6.0 | 2.1 | RAW8 timestamp(ms)| w | h | Zmax | center point (m) (conf) 2469720 | 240 | 180 | 3.1 | 0.0 0.0 0.0 0

As you can see, for SDK 1.5.0, fhe fps is NEVER divided, regardless of the value of standby_enabled.
For SDK 1.6.3, fhe fps is ALWAYS divided, regardless of the value of standby_enabled.
So, my problem is solved but I think you have a bug on the management of the paramater 'standby_enabled'.
I fastly investigate the code of voxl-camera-server and I can't find where you are using 'standby_enabled'. Here is the search result in all the project :

# Query: standby_en # ContextLines: 2 6 results - 2 files include/common_defs.h: 370 modal_exposure_msv_config_t ae_msv_info; ///< ModalAI AE data (MSV) 371 372: int standby_enabled; ///< Standby enabled for lidar 373 int decimator; ///< Decimator to use for standby 374 src/config_file.cpp: 129 printf(" gain_min : %d\n", cams[i].ae_msv_info.gain_min); 130 printf(" gain_max : %d\n", cams[i].ae_msv_info.gain_max); 131: printf(" standby_enabled: %d\n", cams[i].standby_enabled); 132 printf(" decimator: %d\n", cams[i].decimator); 133 printf(" independent_exposure:%d\n", cams[i].ind_exp); 642 // standby settings for tof only 643 if(is_tof_sensor(cam->type)) { 644: json_fetch_bool_with_default(item, "standby_enabled", (int*)&cam->standby_enabled, cam->standby_enabled); 645 json_fetch_int_with_default (item, "decimator", &cam->decimator, cam->decimator); 646 }

Maybe you should add a condition in your function PerCameraMgr::ProcessTOFPreviewFrame():

void PerCameraMgr::ProcessTOFPreviewFrame(mpa_ion_buf_t* buffer_info, camera_image_metadata_t meta) { tofFrameCounter++; if(grab_cpu_pitmode_active() && tofFrameCounter % (int)configInfo.decimator != 0){ return; } auto noStridePlaneSize = static_cast<size_t>(pre_width*pre_height*1.5); auto realWidth = static_cast<uint32_t>(pre_width*1.5); uint8_t* noStridePlane; if (buffer_info->stride != realWidth) { noStridePlane = new uint8_t[noStridePlaneSize]; removePlaneStride(buffer_info->stride, realWidth, buffer_info->height, (uint8_t*) buffer_info->vaddress, noStridePlane); } else { noStridePlane = static_cast<uint8_t*>(buffer_info->vaddress); } uint16_t srcPixel16[pre_width * pre_height] = {0}; // NOTE we don't actually puvblish tis particular metadata to the pipe // TOF data is published separately in a very different way to cameras meta.format = IMAGE_FORMAT_RAW8; meta.size_bytes = pre_width * pre_height; meta.stride = pre_width; Mipi12ToRaw16(meta.size_bytes, noStridePlane, srcPixel16); tof_interface->ProcessRAW16(srcPixel16, meta.timestamp_ns); if (buffer_info->stride != realWidth) { delete[] noStridePlane; } M_VERBOSE("Sent tof data to royale for processing\n"); return; }

Best regards
Quentin

@tom Thank you!

Update fix

Replace defaults.parm with upstream version: https://github.com/ArduPilot/ardupilot/blob/ee1e4bbf74061760826b17464383d63c1a11924c/Tools/Frame_params/ModalAI/Starling2Max.parm Rename Starling2Max.parm to defaults.parm in /data/APM Edit SERIAL3_BAUD=9 (in defaults.parm) Edit GPS1_TYPE=2 (in defaults.parm) Remove *.stg files in /data/APM Reboot and power off the voxl2 multiple times, checking the gps driver

@Gerhold-Ten-Voorde , have you considered adding a spacer between the camera sensor PCB and the current lens holder? At least for testing purposes, that should work.

I will check if we can share the lens holder part numbers.

Alex