@Rowan-Dempster ,

Please see the following commit where we recently enabled publishing the normalized frame from IMX412 and IMX664 camera via regular and ION buffers: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/commit/c42e2febbc6370f9bbc95aff0659718656af6906

The parameters for 1996x1520 look good, basically you will be getting 2x2 binned (full frame) and then further down-scale to 998x760. since you are doing exact 2x2 downscale in misp, you can also remove interpolation, which will make the image a bit sharper, you can see this for reference: link -- basically change the sampler filter mode from linear (interpolate) to nearest. If you use non-integer down-sample, keep the linear interpolation.

Regarding the resolution to use with VIO.. i think the 998x760 with nearest sampling should behave the same or better than AR0144 with 1280x800 resolution, mainly because the IMX412 has a much bigger lens (while still being pretty wide), so image quality is going to be better (of course, you need to calibrate intrinsics). Also the 4:3 aspect ratio may help capture more features in the vertical direction. That of course does not account for rolling shutter effects..

There can definitely be benefit in going up in resolution and using 1996x1520, but you kind of have to use the extra resolution correctly.. typically you would detect features on lower resolution image and then refine using the full resolution (also for tracking features). However, in practice, often some small blur is applied to the image to get rid of pixel noise, etc, so very fine features won't get picked up. Unfortunately, we do not know exactly what QVIO does internally. it may do some kind of pyramidal image decomposition to do these things in a smart way. You should try it and check the cpu usage.

Using MISP you can downsample and crop (while maintaining aspect ratio) to any resolution, so it's easy to experiment.

If i had to test QVIO at different resolutions, i would log raw bayer images and imu data using voxl-logger and then use voxl-replay + offline misp + offline qvio to run tests on the same data sets with different processing parameters. This may sound complicated, but it's really not:

• voxl-logger can log raw10 frames (on this branch) : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-logger/-/tree/extend-cam-logging
• qvio relies on timestamps from incoming messages, so it can work with live data or playback data
• the only missing piece is offline MISP implementation, which is partially available in this tool : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/add-new-image-tools/tools/voxl-convert-image.cpp -- and we are working on being able to run exactly the same implementation as in camera-server. The only missing piece in the code listed here is AWB -- however, white balance should not affect VIO too much, since only Y channel is used, so you can set white balance gains to a fixed value.
• running misp offline allows you to experiment with different resolutions / processing directly from the source raw10 bayer image (lossless)

So, if you are really serious about using hires camera for QVIO, since there are a lot of unknowns, you should consider setting up an offline processing pipeline, so that you can run repeatable tests and parameter sweeps. It requires some upfront work, but the pay-off will be significant. You can also use the offline pipeline for regression testing of performance and comparing to other VIO algorithms (which just need the MPA interface). We can discuss this topic more, if you are interested.

imx412_fpv_eis_20250919_drivers.zip are the latest for IMX412. We should really make them default ones shipped in the VOXL2 SDK, but we have not done it.

Since you are maintaining your own version of voxl-camera-server, you should add them to your voxl-camera-server repo and .deb and install them somewhere like /usr/share/modalai/voxl-camera-server/drivers. then modify the voxl-configure-camera script to first look for imx412 drivers in that folder and then fallback to searching /usr/share/modalai/chi-cdk/. In fact this is something I am considering, as maintaining camera drivers in the core system image is less flexible.

EDIT: i guess the older version of the imx412 drivers are already in the repo, so you can just replace them with new ones in your camera server repo: link

Let me know if you have any more questions. Sounds like a fun project

Alex

@Myles-Levine , if you are masking out 90% of down-facing camera, then it is probably useless any movement of the features will get it out of the unmasked region very easily and feature will be dropped.. It may hurt VIO as there may be features going in and out, only trackable for a few frames (just adds to the complexity).

You should try to move the down-facing camera to free up it's FOV or even have it facing slightly angled to the back of the drone..

Alex

Hello @Catalystmachine ,

Sorry for the confusion. We have updated the page to be more clear that Boson is not included, see below: "(No Boson)" was added to the kit description.

The title of the product already states "VOXL 2 MIPI Boson+ Adapters for Thermal IR FPV" as well as the Kit description used to say (Before we added (No Boson)) : "PCB Adapters Only..."

The price of the Boson cameras varies significantly, depending on the specifications. You can contact a distributor to get more details. For example : https://www.oemcameras.com/product-category/thermal-imaging-cameras/thermal-imaging-cores/flir-boson-series-htm/boson-plus/ (you can find more at https://oem.flir.com/contact/find-a-dealer/)

Please note that Boson+ series of the Boson sensor is required for compatibility with VOXL2.

Regarding the pricing of the adapter kit, we do offer discounts in higher volumes, if you are interested, please send us a request: https://www.modalai.com/pages/contact-us

@Myles-Levine
Performance is evaluated with no external masks -- as we don't ship them. With masks, the answer is very dependent on use-case. Honestly, based on practical tests, it might be better to fly single-cam (full-view) with tight params for robustness than to fly multi-cam with obstructed view. Furthermore, you could try changing the location of your cameras, and doing an extrinsic IMU-CAM calibration with our Kalibr setup (guides available in past answered questions)

@Myles-Levine Absolutely, you're forcing the tracker to reduce the tracking continuity window, less persistent features -> SLAM feats drop.

Perhaps, you could try reducing the spacing between features in the estimator_config yaml (track opts) to bump MSCKF feats and potentially SLAM feats; however, these are advanced settings. Please exercise your best judgment when changing this, modifications are not recommended for general/default use-case

@zauberflote1
You could also disable the bottom cam in vio_cams.conf for VIO only

@Myles-Levine
Hello There,

Please check your SDK version, VINS is under constant development, so always prefer the latest tag available.

Regarding occlusion during takeoff, please check your /etc/modalai/vio_cams.conf, if you have the occlusion flag during takeoff enabled, I would attempt disabling and confirm if the behaviour persists...

Regarding Arbitrary mask, please refer to this past forum question, if you have any further questions, please don't hesitate to post.

All the best,
ZBFT

@qubotics-admin First you need to determine the version of PX4 running. With ssh or adb you can run the following at the command line: px4-ver all. You will see PX4 version and Vendor version. So, for example, for px4 version 1.14.0 and vendor version 8.134.3 then you would checkout the tag v1.14.0-8.134.3-dev from the repo to see that commit.

@Kashish-Garg-1 , please see the following discussion regarding M0149 without an IR filter as well as a lens part to reference if you want to buy replacement lenses only.

If you would like to use M0149 (as opposed to M0166), the best approach would be to buy the M0149 cameras in original configuration (with IR filters) as well as additional lenses without IR filter and then swap the lenses (use contact form for a custom order with lenses). Sorry, we won't modify the standard M0149 units. I hope this helps!

Please note that lenses that are shipped with M0166 are about 1mm shorter in Z direction (along the optical axis) compared to the lenses shipped with M0149, however the lens specs are very similar. Please perform testing to ensure compatibility for your application.

https://forum.modalai.com/topic/4826/msu-m0149-1-ir-filter

Alex

@groupo , sorry, you are right, an update is overdue. Please give us a few more days to provide an official response.

Alex