@Eric-Katzfey Hi!
Are there any examples, case studies, or helpful resources on modifying or adapting VOXL2 to use a different sonar sensor?

@Vinny Thank you for reply!

Unfortunately, I need to connect two cameras to the J11 port. I’m planning to connect other sensors to the J10 and J12 ports.
I will first test by connecting one camera to the J11 port, and then try using a USB hub with a 1A capacity.

Although it appears as a single line in the hardware architecture diagram, the connections to the USB hub were made individually!

@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

@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

@Cliff-Wong Yes, I can confirm that flying manually in Position mode works correctly and accurately follows the XYZ coordinates shown in the voxl-portal VIO page. Additionally, the drone successfully performs the figure 8 trajectories in offboard mode as expected.

The readme to help you use my scripts :

./readme.md :

# VOXL USB NCM Setup for ModalAI Starling 2 Max ## Context & Objective > This repository provides scripts and configuration files to enable **USB NCM** (Network Control Model) networking between a **ModalAI Starling 2 Max** drone and a **Linux PC**. The goal is to transfer files faster than **Wi-Fi** or **ADB**, using a direct USB Ethernet link. **USB NCM** creates a virtual Ethernet interface over USB, allowing high-speed IP communication for **SSH**, `rsync`, or other tools. --- ## Features Automatic configuration of USB NCM on both drone and PC. Systemd services to persist configuration across reboots. NetworkManager drop-in to prevent interference on the PC. IP addressing and MTU tuning for optimal performance. ## Installation Run the orchestrator script from the root of this repository: ```bash chmod +x config-voxl-usb-ncm.sh # Already executable normally ./config-voxl-usb-ncm.sh

Options

--pc : Configure only the PC. --drone : Configure only the drone (requires adb). --uninstall : Stops and disables services, removes scripts, and cleans NetworkManager configuration.

Exemples

# Install on both PC and drone ./config-voxl-usb-ncm.sh # Install only on PC ./config-voxl-usb-ncm.sh --pc # Install only on drone ./config-voxl-usb-ncm.sh --drone # Uninstall everything ./config-voxl-usb-ncm.sh --uninstall # Uninstall only on PC ./config-voxl-usb-ncm.sh --pc --uninstall # Uninstall only on drone ./config-voxl-usb-ncm.sh --drone --uninstall Configuration Details IP Addresses Drone: 10.55.0.1/30 on usb0 PC: 10.55.0.2/30 on enx* (USB Ethernet interface) MTU Default: 1500 (After some tests, 1500 seems to be the maximum for NCM in USB2.1) Systemd Services Drone: voxl-usb-ncm.service (oneshot, sets up USB gadget and configures usb0) PC: voxl-usb-ncm.service (persistent, monitors enx* and configures IP) NetworkManager Adds /etc/NetworkManager/conf.d/unmanaged.conf which prevents NetworkManager from interfering with the USB interface. How to Connect

Once installed and both devices are connected via USB:

# It will ask password ssh root@10.55.0.1 # We can put the password in parameter by using sshpass. # By default, the password on the drone is oelinux123. sshpass -p oelinux123 ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@10.55.0.1 File Transfer with rsync # Example to copy a folder from PC to drone: rsync -ah --info=progress2 --partial --inplace /path/to/local/folder root@10.55.0.1:/path/on/drone/ # Example to copy a folder from drone to pc: rsync -ah --info=progress2 --partial --inplace root@10.55.0.1:/path/to/drone/folder /path/on/pc File Overview File : on_drone/voxl-usb-ncm-setup.sh Destination : /usr/local/sbin/ on drone Purpose : Creates USB gadget NCM function, configures usb0 with IP 10.55.0.1/30 and MTU File : on_drone/voxl-usb-ncm.service Destination : /etc/systemd/system/ on drone Purpose : Runs setup script at boot (oneshot) File : on_pc/voxl-usb-ncm-setup.sh Destination : /usr/local/sbin/ on PC Purpose : Monitors enx* interface, assigns IP 10.55.0.2/30 File : on_pc/voxl-usb-ncm.service Destination : /etc/systemd/system/ on PC Purpose : Starts monitoring script at boot File : on_pc/unmanaged.conf Destination : /etc/NetworkManager/conf.d/ Purpose : Marks enx* interfaces as unmanaged File : config-voxl-usb-ncm.sh Purpose : Orchestrates installation/uninstallation on PC and drone

Hi @Jetson-Nano
The connectors between VOXL 2 and M0173 are DF40's. They are rated for 30 cycles:
04a17618-1ea9-4b38-8552-804d68ecda65-image.png
The uCoax image sensor cables are also from Hirose, and are much more fragile. They are rated for 20 cycles, but to be honest, I break them after 3-5 cycles personally if I am not using a tool. With the use of the proper tool we specify here, you should get to 10-20 cycles.
https://docs.modalai.com/micro-coax-user-guide/
8cd3250a-ffcc-497a-ae4f-d2cdb9f2d346-image.png

FCv2 uses a bunch of JST GH connectors. On the flip side, I've never broken one of those! 🙂
JST sadly does not specify the cycle count. So, any number we provide would be a guess. We use it due to DroneCode compliance intentions. They are pretty robust and never experienced any issues.

Hope this helps.

@cguzikowski , you need to update your camera server to allow misp to accept the new resolutions. You can install the latest one from voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/

@Jesus-Cardenas It should now be updated!

Should be available on our new Downloads page: [https://modalai.filecloudonline.com](link url) , inside the Flat Builds Folder

@spiff You'll likely need to reach out to Sierra Wireless directly for debug help.

@SKA , thank you for providing all the information. We are doing more testing and will get back to you. So far cannot reproduce.

Alex

@minhthinh The params are in our voxl-px4-params repo. For example: https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-px4-params/-/blob/master/params/v1.13/Platforms/M500_FCV2.params?ref_type=heads

@Alex-Kushleyev Hi Alex,

Thank you for the clear and concise explanation.

@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

@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

@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