@Jetson-Nano As suggested before, can you disable the rangefinder and optic flow and see if things work with VIO alone?

Hey @Eric-Katzfey I was able to solve it. I was able to shift the drone to offboard-mode, the drone doesn't drift away. In voxl-vision-hub, I have the set the parameter to figure_eight.

I'm getting the stream to VOXL2 from Flight Core v2. I had to run it on 2 different ports.

mavlink stream -r 30 -s ODOMETRY -d /dev/ttyS4
mavlink stream -r 30 -s ODOMETRY -d /dev/ttyS6
But I'm getting the #331 odometry message when using only ttyS6 port.

Screenshot from 2024-11-25 18-52-49.png

Now the drone is able to figure_eight loop without loosing height estimates.

@svempati, sounds good, let me know if you run into any issues.

You should always test new VIO changes without flying first, by holding the drone in your hand and carrying it around.
If you set it up and QVIO "blows up" as soon as you start moving the drone, this most likely means incorrect extrinsic parameters (most likely camera to imu rotation).

Alex

@Alex-Kushleyev thanks for clarifying this! I tracked the voxl-qvio-server source code and the mvVISLAM.h library documentation. It is clear that only fused data is available and now I also know why thanks to your explanation @Alex-Kushleyev. I am working with an engineer who is dealing with stereo visual odometry so in this case it is possible to get the visual odometry without the IMU fusion also. @Eric-Katzfey it seems that you did not understand my question, but Alex's answer was perfect, thanks anyway. 🙂

@Cliff-Wong Thanks for your detailed guidance, helps a lot! #2 is actually what I was originally aiming to do, since I am actually doing simulation stuff with PX4 SITL so I can turn off GPS without consequences. Will try the other steps when we are ready to run it on hardware.

@teng , you should be able to run multiple independent instances of QVIO, but our scripts are not set up to do that. You would need to do the following (the list may not be complete..):

create a second voxl qvio server config and populate it with appropriate changes calibrate the second camera and update the path to intrinsics in the second qvio server config update the extrinsics calibration file for second camera and use it in qvio server config you will probably need to change the qvio output message / pipe names, otherwise they will conflict with the first instance. there is also a check if the process is already running (in qvio server main.cpp), so you would need to bypass that check.

Alex

@SKA Yes, VFT is actually deprecated in 1.4.1

Please replace your ovins config with this and give it a try:

@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.

@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?

@Alex-Kushleyev Thank you very much!

@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

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

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

@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