@zauberflote1
Thank you for your support. I followed your advice and changed the settings again today.
It's much better than yesterday, but the reduction in feature points is still there. I've made a video of the current situation, so please check it out.
https://www.youtube.com/watch?v=H-_lLwPrPOE

I would like to ask some questions today as well, so thank you in advance.

Support Request: VIO Instability on Custom Drone Frame (Compared to Stinger) - Follow-up Summary

We have successfully configured a VOXL 2 Mini on a Stinger frame (D0013) with SDK 1.6.2, and VIO works perfectly in our indoor environment.
However, we are facing persistent VIO instability on our custom drone frame, which uses the same VOXL 2 Mini and camera sensors, despite trying extensive troubleshooting.

The core issue is that feature points drop to 0 and VIO quality drops to 0% specifically when the drone is hovering or stationary. Paradoxically, when we move the drone or shine a bright light on the floor, the feature count improves and VIO holds for longer.

Update: After fixing camera extrinsics and setting sync_config: false, VIO performance improved significantly ("much better than yesterday"). However, the issue persists: feature points still drop to 0 during hovering, while Stinger maintains ~22 features in the same conditions.

Hardware Setup Flight Controller: VOXL 2 Mini (SDK 1.6.2) Cameras: tracking_front (Ar0144) tracking_down (Ar0144, rotated 90 degrees) Note: This custom frame DOES NOT have a Hi-Res camera. It only has 2 tracking cameras. However, since selecting "Tracking only" in the SKU configuration prevented us from entering Position Mode, we configured it as "Hi-Res + 2 Tracking" and then manually disabled the hires camera in voxl-camera-server.conf. Frame: Custom frame (Carbon fiber), designed in CAD by ourselves. Note: We identified that the frame was reflecting into the camera view. We have covered the reflective parts with black tape, which improved stability slightly but did not solve the issue. Camera Positions relative to IMU (FRD coordinate system): FRONT camera: Forward (X): +70.8mm Right (Y): -19.4mm (Left direction) Down (Z): -20mm (Up direction) DOWN camera: Forward (X): +38mm Right (Y): -19.4mm (Left direction) Down (Z): +9mm (Down direction) Camera Calibration: Both FRONT and DOWN cameras have calibration errors ≤ 0.3 (excellent calibration quality). Camera Focus: Focus is properly adjusted for both cameras. Symptoms Hovering/Stationary: There are no issues when the drone is constantly moving. However, when it remains stationary for more than 10-20 seconds, feature points (num_pts) gradually decrease and eventually hit 0. VIO Quality then drops to 0%. Moving/Flight: When moving the drone (in flight or by hand), feature points increase to the max of ~30 and VIO recovers. Lighting: Shining a strong light on the floor extends the time before VIO fails, but it eventually drops to 0. Comparison: A Stinger drone in the exact same indoor environment and lighting holds position perfectly with default settings, maintaining ~22 features even when stationary. Recent Troubleshooting Steps (Today) IMU Noise Parameter Testing

We compared kalibr_imu_chain.yaml between Stinger and our custom frame and found they have identical values. Since different frames should have different noise characteristics, we tested adjusting IMU noise parameters:

Increased to 1.5x: No noticeable difference Decreased to 0.8x: Performance worsened Increased to 2x: Position mode could be maintained, but the drone oscillated (wobbled) excessively Reverted to default: Best performance

Conclusion: IMU noise parameters are not the root cause. Default values are optimal.

Previous Troubleshooting Steps (All Reverted to Default)

We have tried the following configuration changes, but none provided a permanent solution, so we have reverted everything to default settings (except for necessary fixes):

VIO Config (estimator_config.yaml): Tried zupt_only_at_beginning: false (to enable ZUPT during flight). -> No effect / Worsened. Tried increasing num_pts (50 -> 150) and lowering fast_threshold (15 -> 5). -> VIO stopped working completely. Camera Config (voxl-camera-server.conf): Tried increasing exposure_max_us (12ms -> 33ms). -> QGC rejected position mode more strictly. Tried increasing gain_max (8000 -> 16000). -> No significant improvement. IMU Config (voxl-imu-server.conf): Tried lowering imu0_lp_cutoff_freq_hz (92Hz -> 42Hz, 30Hz, 20Hz). -> No effect. FFT analysis showed 200-240Hz vibrations, but filtering them did not improve VIO. Stinger shows similar vibrations but stable VIO. Calibration: Performed voxl-calibrate-camera with the frame taped to prevent reflections. Updated extrinsics.conf and kalibr_imucam_chain.yaml with precise physical measurements. OpenVINS Config (voxl-open-vins-server.conf): Set sync_config: false (based on support advice). -> Significant improvement. Tried sync_config: true (to match Stinger). -> Performance worsened. Current: sync_config: false (required for custom frame). Current Configuration SDK: 1.6.2 voxl-vision-hub.conf: en_vio: true, vio_pipe: ov (OpenVINS), offboard_mode: vfc voxl-open-vins-server.conf: sync_config: false (required for custom frame) voxl-camera-server.conf: Default exposure (12ms), hires disabled. estimator_config.yaml: Default (OpenVINS default). voxl-imu-server.conf: Default (92Hz). kalibr_imu_chain.yaml: Default (same as Stinger). kalibr_imucam_chain.yaml: Updated with precise physical measurements for camera extrinsics. Key Differences from Stinger sync_config: Stinger works with sync_config: true, but our custom frame requires sync_config: false. Feature point behavior: Stinger maintains ~22 features when stationary, while our custom frame drops to 0. IMU noise parameters: Identical values, but custom frame may have different vibration characteristics. Question

Why does the custom drone fail to maintain feature points in the same environment where the Stinger works perfectly?

Since:

Frame is designed in CAD with precise measurements Extrinsics are correctly measured and configured (FRONT: Forward 70.8mm, Left 19.4mm, Up 20mm; DOWN: Forward 38mm, Left 19.4mm, Down 9mm) Camera calibration errors are ≤ 0.3 for both cameras (excellent quality) Camera focus is properly adjusted sync_config: false is required (unlike Stinger) IMU noise parameter adjustments don't help Frame reflections are taped off

What other factors could cause OpenVINS to lose feature points specifically during hovering/stationary periods on a custom frame?

We have attached the following configuration files:

kalibr_imu_chain.yaml　https://drive.google.com/file/d/1xk3hV08xkCsr_76CaHUp71kmJrE4qDip/view?usp=sharing kalibr_imucam_chain.yaml
https://drive.google.com/file/d/1fTq8KKdH1gERFFMk34GBBJd5IRFqAw9Z/view?usp=sharing estimator_config.yaml
https://drive.google.com/file/d/1vtH50HK-VgsAOCAZEtjA27-kU0kD_aic/view?usp=sharing voxl-open-vins-server.conf
https://drive.google.com/file/d/1seNpGRoWwLbVvCMlXYlQeMPOkTn04nc0/view?usp=sharing

@Sarika-Sharma ,

The preview width and height parameters are always in the camera config file, so if you added them, they are duplicates (and will be ignored).

Please read through this thread as it has pretty detailed explanation how to configure the correct tof sensor (old or new) for a custom configuration.

Camera-server-config-helper is indeed helpful. If you use it correctly, you should not have to manually modify the resolution in the config file.

If you still cannot get this to work, please let me know what cameras you have plugged in (and which camera ports) on your voxl 2 mini.

Alex

@Sarika-Sharma Now TOF is detected. I have choosed pmd-tof instead of pmd-tof-liow2.
But please give solution for the following problem.
When I used J7 according to the following configuration
Hardware Setup
M0104 Connector Interposer Sensor HW ID
J7 M0135 JL Tracking (M0014 ) 2
J7 M0135 JU Hires (M0025-2 ) 3
OR
J7 M0135 JL Hires (M0025-2 ) 2
J7 M0135 JU Tracking (M0014 ) 3

ONLY , The camera which is connected to JL is working either tracking or hires.
Cameras connected to JU is not working.
When i run voxl-camera-server it gives this
WARNING: cam tracking (id 1) does not seem to be alive

------ voxl-camera-server: Started 1 of 2 cameras

------ voxl-camera-server: Camera server is now running
OR
When i run voxl-camera-server it gives this
WARNING: cam hires (id 1) does not seem to be alive

------ voxl-camera-server: Started 1 of 2 cameras

------ voxl-camera-server: Camera server is now running/home/idr/Downloads/WhatsApp Image 2025-12-26 at 5.31.01 PM.jpeg

@Alex-Kushleyev
Thank you!

What is the procedure to provide design for review?

@Sarika-Sharma Kindly resolve this issue also https://forum.modalai.com/topic/4952/pmd-tof-not-detected-on-voxl2?_=1766730439331.

For anyone reading this in the future this works:

docker run --rm --privileged \ -v "$SYSTEM_IMAGE_DIR":/system-image:ro \ -v "$CLEO_IMAGE_DIR":/cleo-image \ -v "$CLEO_PROVISION_DIR":/cleo-provision:ro \ ubuntu:18.04 bash -c " set -e # Install tools apt-get update -qq apt-get install -y -qq android-tools-fsutils e2fsprogs >/dev/null # Extract stock data partition contents echo 'Extracting stock m0054-data-fs.ext4...' mkdir -p /tmp/data_root # Convert sparse to raw and mount simg2img /system-image/m0054-data-fs.ext4 /tmp/stock_raw.ext4 mkdir -p /mnt/stock mount -o loop,ro /tmp/stock_raw.ext4 /mnt/stock # Copy all stock files cp -a /mnt/stock/* /tmp/data_root/ umount /mnt/stock rm /tmp/stock_raw.ext4 echo 'Stock contents copied.' # Add cleo-provision directory cp -a /cleo-provision /tmp/data_root/cleo-provision echo 'Added cleo-provision directory' # Create the ext4 image using same parameters as BitBake recipe: # -s : sparse output # -l SIZE : filesystem size in bytes # -a /data : android mount point # -b 4096 : block size make_ext4fs -s -l $USERDATA_SIZE_EXT4 -a /data -b 4096 /cleo-image/m0054-data-fs.ext4 /tmp/data_root echo '' echo 'Created sparse ext4 image successfully' "

You'll need to be on an arm64 architecture.

@voxltester Why are you not adding -b 4?

Hello @HsinSWT ,

When i see results like this, i would say there is probably 90% chance that the motor is bad. Unfortunately, there is a chance that the ESC is bad as well, and there is no good way to check the ESC without a known good motor (however the ESC failure is unlikely).

As I mentioned in the previous post, if you had a milli-ohm meter, you could test the motor winding resistance to confirm whether the motor is good or bad. A tool like that measures resistance with high precision (similar to a regular Ohm meter). However, if you don't have one, it may not be worth buying it..

You will not be able to measure the winding resistance of these motors correctly with a regular Ohm meter. However, you will be able to detect a complete open circuit (which could be the case, maybe worth trying). If testing resistance using a regular Ohm meter, any two connections between the 3 motor phases will read 0 ohm (or close to that). If a wire is broken, then you can detect it.

The Starling 2 motor (3000kV) has around 0.360 - 0.370 Ohm phase-to-phase winding resistance.

In order to confirm that the ESC is working properly, you could temporarily connect one of the working motors to the ESC Channel 0 and do the same spin test (using voxl-esc tools), just to confirm that the ESC Channel 0 is working fine.

In order to fix the issue, you could order a new motor and replace it yourself (will be a lot cheaper): https://www.modalai.com/products/starling-2-replacement-parts?variant=49707605393712

You could also send the whole drone back for repair (https://www.modalai.com/rma)

Alex

@Alex-Kushleyev Thanks for the help !

@Alex-Kushleyev Thanks for detailed information and analysis. I am going ahead with further testing with this ESC as per your suggestion.

I have changed my propulsion system as follows: Emax Eco II seroes 2306 2400kv motor, propeller Gemfan 5177 and 15000 mah 4S battery.

Here is my file with ESC calibration : https://drive.google.com/file/d/1uzbx9MGwF1EvRqJx6tXBqqc-j3XZSgu_/view?usp=sharing

All the motor directions are checked and they are correct as per airframe reference. My UAV is able to takeoff a bit but at around 0.5 meters it again decreases its altitude and then after scratching the surface is flipping over.

Here is the logs : https://review.px4.io/plot_app?log=08691d7d-887d-41d8-b00d-d543febeea59

Can you spot is my ESC configuration wrong or anything I am missing in PX4 configuration? This flip happened twice in a row and all motor direction are verified to be correct since UAV is able to takeoff. Also any advantage of RPM vs PWM control in VOXL ESC PX4 parameter setup?

Also my voxl2 is unpside down so I have set ROLL_180 in Autopilot orientation, but is this creating some problem anywhere is unknown since I can see yaw reset EKF2 estimator flag set as soon as I takeoff.

@tom , what would be the right course of action here? Thanks!

Hello @awagner ,

I am sorry this happened to you. A few questions / comments:

It seems your motor is too large for this mini ESC

https://docs.modalai.com/voxl-mini-esc-datasheet/

"This Mini ESC is designed for aerial vehicles under 750g (under 500g for FPV racing applications). For larger slow flying vehicles up to 1500g, please use the VOXL 4-in-1 ESC. For FPV racers exceeding 500g, please use VOXL 4-in-1 FPV ESC."

the kp value is very aggressive (typically i would recommend starting at 0 kp and ki (proportional and integral gains) and ramp those up to increase responsiveness.

the spin-up type should be set to 1 (sinusoidal), since it is much more reliable. Which parameters did you start with when you calibrated your ESC? i suspect that improper spin-up caused the ESC to get out of sync and fail due to excessive current.

I know it can be difficult to get started with using new hardware. Aside from the need for updated esc parameters, the issue here is that the mini ESC is not suitable for your motors / propellers. I strongly recommend upgrading to our FPV ESC , which is build to handle a lot of power and stress:

https://www.modalai.com/products/m0138 https://docs.modalai.com/voxl-fpv-esc-datasheet/

Once you get the FPV ESC, I can help with the tuning (let me know, i can provide updated params before you test gain).

Please submit an RMA request, https://www.modalai.com/pages/rma . I would recommend at least a discount on the new ESC. We will try to improve documentation to avoid this in the future.

Alex