@Rowan-Dempster , Thanks for the update!

On my end, I did not get a chance to enable MISP pipeline (normalization in particular) to run offline. Let me double check something with you - would you want to load a log with raw10 and resize + generate the normalized image (of a different size) or just keep the same size as input?

Since you have the basic rolling shutter QVIO working, it would be interesting to see how that compares to the AR0144 QVIO from the same data set. Any details you would like to share? (only if you want to)

Regarding playback results from QVIO output not being exactly repeatable -- " no deterministic mechanism to ensure that voxl-qvio-server initializes using the same camera frame" -- what do you mean by that? if you start QVIO and start feeding the frames + imu data from voxl-replay, the data should arrive into QVIO repeatably and QVIO should initialize on the same frame - after the initialization conditions have been satisfied.

If I remember correctly the way QVIO app works is that it may hold the frame until all the IMU data for that frame has arrived and then pushes the frame into the QVIO algorithm. If you push the frame before pushing all the IMU data, then the algorithm will still process the frame but it wont have the IMU data for the whole duration of the frame capture.

The frame capture duration for global shutter cameras is simple :

• start = start of exposure
• end = end of exposure = start of exposure + exposure time
  (i believe it is common to assign a timestamp which is equal to the center of exposure, which is between the start and end timestamps).
• center of exposure = start of exposure + (exposure time)/2

In order to find the center of exposure for rolling shutter camera, you need to use the following formula, as used in our EIS implementation in MISP:

int64_t center_of_exposure_ns = start_of_exposure_ns + (exposure_time_ns + readout_time_ns)/2;

In any case, this would be something to double check.. also i don't know how far your trajectories are from run to run.

Another tip: since you don't have ground truth in your data, it helps to start and end your data collection in exactly the same spot and orientation, so you can use the end position drift as a good metric (ground truth).

Alex

@cbay ,

Here is the diagram for M0188 showing resistor R10 and R11 that need to be added (0 ohm) in order to connect the sync signal to the camera slot 1 and 3.

For some historical reasons, these resistors were DNI'ed in order to prevent (incorrectly configured) hires cameras from outputting a sync signal and interfering with the tracking cameras.

Please be careful when adding the resistors, as spacing between components is pretty tight.

We will update the docs for M0188, M0195 and M0173 to reflect the default state and how to enable the sync on the camera ports that do not have it already connected.

I have just tested this on voxl2 using SDK 1.6.3 and it seems to be working. The prints were updated, but what you see is normal (i saw the same messages). Did you check dmesg for any errors from wifi dongle? I used the following wifi adapter, which is unfortunately EOL (with our M0141 expansion board) :

────────────────────────────────────────────────────────────────────────────────
system-image: 1.8.06-M0054-14.1a-perf
kernel:       #1 SMP PREEMPT Wed Oct 22 04:13:18 UTC 2025 4.19.125
────────────────────────────────────────────────────────────────────────────────
hw platform:  M0054
mach.var:     1.0.1
SKU:          MCCA-M0054-C8
────────────────────────────────────────────────────────────────────────────────
voxl-suite:   1.6.3
────────────────────────────────────────────────────────────────────────────────
no current network connection
────────────────────────────────────────────────────────────────────────────────

voxl2:/$ voxl-wifi station xxxxxx yyyyyy
Detected WiFi interface: wlan0
NetworkManager not installed, using legacy wpa_supplicant/hostapd
stopping softap mode
Enabling station mode on wlan0 (legacy)...
creating wpa_supplicant configuration for station mode
Station mode enabled on wlan0
Station mode configured!

voxl2:/$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=118 time=11.806 ms

cross-posting the reply here as well, since this is more relevant thread:

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

@Aniruddha , we currently do not have an option to order this via our online shop, but you have some other options:

• email us using contact form and request a custom order of those parts : https://www.modalai.com/pages/contact-us
• download the CAD model (https://developer.modalai.com/asset) and 3D print the part(s) yourself or order them to be printed. We use MJF material for these parts.

Sorry for the inconvenience. We will look into making the spare part ordering process easier.

Alex

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

@cbay , thanks for clarifying

On M0188, J1 and J3 do not have the sync signal connected. We will release a diagram shortly showing where to install 0-ohm resistors on M0188 to connect the sync signal to the corresponding camera ports.

And you will need fsin drivers for J0, J1, J2, J3 (will share them shortly as well)

By default, the AR0144 tracking cameras are connected to J0 and J6 (camera slots 0, 6), which are actually connected to a single CSI interface and are used in a combo mode (two 1-lane (mipi lane) cameras merged into a single 4-lane mipi interface).

Note that when the fsin or combo (combo mode drivers also use input trigger) are used, but there is no actual sync / trigger signal getting to the camera, then there will be no frames produced. This is specific to the AR0144 camera, as other cameras may operate differently and use the sync signal to align the readout trigger (so in absence of trigger signal, those cameras would simply be not sync'ed, but AR0144 just does not send any frames)

Alex

@qt , there is a "decimator" param, which reduces the TOF fps in standby mode (when drone is not flying) in order to reduce the cpu usage, since the TOF processing software can use substantial cpu depending on the FPS. https://docs.modalai.com/voxl-camera-server/#camera-server-config-file

in your case, the decimator is set to 5, but i also see that "standby enabled" is set to false, so perhaps there is a bug that still applies the fps decimation.

Can you please try setting the decimator to 1 and see if that resolves your issue and we will double check if the standby_enabled parameter is not working correctly.

Alex

@SKA ,

Most of the supported cameras (except for Boson, Hadron) have their reset signal connected to VOXL2, so when the cameras are not in use, they are shut down via the reset pin. This means that the camera modules may still get power, but they are shut down.

There are many power rails and interposers - some power rails remain on all the time (5.0, 3.8V) and others may be shut down by PMIC when not in use. Different cameras use different power rails for their operation, so it is hard to answer this question without knowing the specific use case.

Alex

@jameskuesel ,

For item 1, (a frame from hires recording with eis), you can do this already by just capturing the YUV from the hires_misp_color stream. you could do this using existing tool voxl-record-raw-image.

For item 2, the full frame can also be captured (using the same tool) but only in raw bayer format. This would be good for offline processing, if you wanted to get the maximum image quality, however this image would not have any processing applied from MISP.

Additionally, since MISP supports multiple outputs, as you already know, (misp channels), you could set up one channel to be a full frame image (which you normally dont stream), with EIS off.

So with correct voxl-camera-server.conf, you should be able to get all the streams you want

• full frame
• hires recording
• low-res streaming

And grab YUVs from any of those streams. The last part would be then just encoding them to JPG (which could be done separately or part of voxl-record-raw-image, which we could add)

If you send me your voxl-camera-server.conf (or the part specific to the hires camera), i can update it to show you how you can get the three streams.

Alex

@bendraper , I will ask around.

Hello @Igor ,

After a quick look your concerns seem valid to me. We will investigate this further and get back to you soon.

Thank you for reporting the issue.

Alex

@Igor and All,

When the IMU is level and at rest, the accelerometer will measure the normal force , which is in the direction opposite to gravity vector. So the normal force will point up (towards the sky) and since the reference frame is FRD (D for Down), the vector that points to the sky will read negative 1g in this frame.

Alex

Hi @Nikola-Rudjer ,

The forum is for technical support -- for sales questions, please reach out to us via https://www.modalai.com/pages/contact-us

Alex

@cbay , OK got it.

In order to synchronize all 4 cameras, you will need:

• use fsin sensormodules for camera slots 2 and 3 -- i will need to provide one for slot 3
• add a resistor to actually enable sync signal for slot 3 (will provide a diagram for M0188)

Meanwhile, you should be able to enable sync for camera slot 2 by using the following sensormodule:
/usr/share/modalai/chi-cdk/ar0144-fsin/com.qti.sensormodule.ar0144_fsin_2.bin instead of com.qti.sensormodule.ar0144_2.bin -- just replace it in /usr/lib/camera/

Also, we have a tool for checking camera sync (you may have to build it yourself from this branch) : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/add-new-image-tools/tools/voxl-check-cam-sync.c -- this is a quick way to check if the timestamps of the frames are aligned.

Alex

@cbay , based on discussion from the other thread (https://forum.modalai.com/topic/5130/running-4-ar0144s-on-m0188), you are running two AR0144 cameras that are synchronized and two unsynchronized.

Can you please clarify which cameras you are using when testing the two-camera open vins setup? If you only have the 4 AR0144 plugged in, then ID0 and ID3 will be synchronized (camera slots 0 and 6) and the other two cameras (cam id 1, 2 - slots 2,3).

Alex

Once you confirm this working, we can discuss the options for snapshots without going through the ISP, but you can either saw the raw bayer or any of the misp outputs using voxl-record-raw-image and convert to jpg / png offline if that works for you, but we can also help add a compression option to voxl-record-raw-image.

Please note that the current debayering algorithm in MISP does add some smoothing / interpolation, so the YUV image is not going to be as crisp as possible. You could compare it to the jpg output of the ISP (even thought it has artifacts). If you are looking for highest possible fidelity, it may be best to perform offline processing on the raw bayer, then you have more options.

Alex

@cguzikowski ,

Good news. I got it working, but there were a few things needed to update. I packaged everything into a zip : https://storage.googleapis.com/modalai_public/temp/ov64b/20260401/ov64b_20260401.zip . It contains

• latest sensormodules for Boson and ov64b
• voxl-camera-server conf
• updated default tuning file (to fix the gain scale so that gain 1.0 is 100, not 54)
• updated com.qti.chi.override.so file which contains some pipeline information, now it will allow the large raw resolutions

(I thought the above changes were already in the latest SDK but somehow they did not make it, I will need to double check).

I also made some changes to the ov64b driver:

• updated frame length for the 9248x6944 mode so that it is 10fps (not 9.2) -- this is close to max
• added modes 9216x6944@10fps and 4608x3472@30fps (slightly cropped on the right), so that these buffers can be used by MISP / gpu without doing a copy.

I am able to capture the raw bayer at 9216x6944, 9248x6944 ,4624x3472, 4608x3472 resolutions

voxl-inspect-cam hires_bayer
...
|   Pipe Name |  bytes  | wide |  hgt |exp(ms)| gain | frame id |latency(ms)|  fps |  mbps  | format
| hires_bayer |79994880 | 9216 | 6944 | 33.00 | 1594 |      130 |    157.9  | 10.0 | 6415.5 | RAW10

In order to enable the misp support for the 4624x3472 and 4608x3472 resolutions in camera server, need a small update:
https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/commit/389b1f4628a9b9cc0e53c43a5cf0e457717e1270

You can save the raw bayer using the voxl-record-raw-image tool, for example:

voxl-record-raw-image hires_bayer -d .

You should be able to dump some raw bayer images and de-bayer them offline.

Also, here is the contents of the README that is inside the zip:

Supported Hardware

• voxl2
• Hadron plugged into VOXL2 J8 via M0181 adapter

Instructions

• copy Boson sensormodule to /usr/lib/camera/
• copy ov64b sensormodule with correct id to /usr/lib/camera/
• copy com.qti.tuned.default.bin to /usr/lib/camera to fix the gain scale (1.0x = 100)
• back up /usr/lib/hw/com.qti.chi.override.so and replace it with com.qti.chi.override.so.20260401 (rename to com.qti.chi.override.so)
  • this updated file allows the pipeline to use the highest resolution of the ov64b camera
• copy voxl-camera-server.conf to /etc/modalai

Suported Resolutions

• mode 0 : 9248x6944 10 bit 10 fps
• mode 1 : 9216x6944 10 bit 10 fps (MISP no copy) -- crop 32 pixels on the right
• mode 2 : 4624x3472 10 bit 30 fps
• mode 3 : 4608x3472 10 bit 30 fps (MISP no copy) -- crop 16 pixels on the right
• mode 4 : 3840x2160 10 bit 60 fps (MISP no copy)
• mode 5 : 1920x1080 10 bit 240 fps
• mode 6 : 1920x1080 10 bit 30 fps

Notes

• even thought the 9248x6944 and 9216x6944 modes are 10 fps, you need to specify 30fps in the camera config file. This will be investigated further.

@bendraper , I just tried this on a Windows 11 VM and even though i was able to see a network device appear in the VM and i configured the IPv4 properties, I cannot ping or ssh. It seems consistent with what you are seeing.

@cguzikowski , OK, yes i know what that issue is (unexpected frame size). I will that and test both resolutions.