@psafi Here are the steps I am taking for camera calibration: 1- run the following command: voxl-calibrate-camera tracking_down -f -s 6x9 -l 0.022 2- look at the overlay in portal (see the screenshot below) 3- calibration process is not progressing automatically even though it seems like the checkerboard is detected [image: 1760465700997-e47c8511-c92f-4ce7-83f6-49d59dd89e7d-screenshot-from-2025-10-14-11-14-52.png]

@Moderator thank you for the recommendation. I will try out this.

Detections is pertinent to voxl-tflite-server and onboard computer vision on yolo, NOT on april tags.

@Moderator Even I am facing the same issue. Did everything as per the instructions on the official website. But unable to calibrate the stereo front. I was able to calibrate stereo back though. I have attached the error along for your reference.

@Daniel-Rincon have you looked through the troubleshooting guide? https://docs.modalai.com/flying-with-vio/#troubleshooting-vio Usually looking at the ovins-overlay in voxl-portal offers good insight The common issues are vibration is too high, the extrinsics are incorrect or there are not enough features to track in the environment

@Cliff-Wong @Kessie Guys can you help me out here.

@tom can anyone help me with this

@Alex-Kushleyev Thank you for reverting, I will check this out and get back to you

@shawn_ricardo Hi! To my understanding EKF2_EV_CTRL 15-->13 only remove EV from pos_z estimation, so it should be ok to do that if the range sensor is active. However, I did revert all parameters to the default settings (matching the VOXL-SDK definitions). As my attempts to integrate the range-sensor data in altitude estimation did not seem to succeed, I decided to try and integrate the range-sensor in the VIO solution. I created a version of the voxl-qvio-server in which pos_z estimation from VIO is replaced by the equivalent value based on the rangefinder: s.T_imu_wrt_vio[2] = - down_range_m; This seem to work better, however it is a workaround and not a full solution. My current experiments are performed in low altitude (~40-90 cm), so I am not concerned with the limited range of the rangefinder sensor. I'm not sure what is the current implemented behaviour when EV estimation is not good, there should be some fall-back relying on the range sensor and imu. From my short experience with such cases of poor EV estimation mid-flight, the drone just crushes or jump to the ceiling with no control. Any suggestions or further explanations will be much appreciated. Thank you

@Eric-Katzfey Thank you for the reply, If I understand correctly, the example you provided shows MAVSDK running directly on the VOXL — so on the drone itself. However, we want to run our script on a separate PC to be able to control all drones at once. We're not sure which port to use to communicate with PX4 while also taking advantage of the relocalization handled by VOXL. Thank you again for your help!

@Alex-Kushleyev Thank you very much!

@SKA What pipes do you see listed in /run/mpa? If you run the command voxl-inspect-vio does it show that VIO is running okay?

@zauberflote1 Hi, So, it’s almost impossible for OpenVINS’ VIO to successfully reset while the drone is in flight if even a simple hand movement (which I always tried to do gently) is enough to prevent proper reinitialization, right? What I used to do to break the VIO was cover the camera, wait for x, y, and z to return to zero, and then uncover it. As for the test environment, it's rich in features, so I don't think that's the issue. I increased the publish and tracking frequency because I wanted to ensure the VIO was "responsive," and with two or three cameras, I consistently achieved reliable results.

@Moderator Sorry, I forgot to mention VOXL Mapper by using the TOF Sensor. I found a table that states it will be supportet in the future: https://docs.modalai.com/M0178/?utm_source=chatgpt.com Do you know when we can expect it ?

@SKA Yes, VFT is actually deprecated in 1.4.1 Please replace your ovins config with this and give it a try: