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

@Madelyne-Rossmann , sounds good! We will work on enabling larger resolutions for calibration and tag detection. It is a bit of a hassle due to very large frames, so some optimizations need to be made. Alex

Problem solved, Thanks anyway

@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

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

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

@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

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. [image: 1732544018893-screenshot-from-2024-11-25-18-52-49.png] Now the drone is able to figure_eight loop without loosing height estimates.

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

Spot on @Matt-Ooi - the voxl2 is natively meant to handle transformations for ardupilot and px4 - BUT you are using MAVROS which is a different tranformation all together - hence why you would have to do the transofmratio yourself before sending into the flight stack running ardupilot (aka when calling mavros offboard) or something

@plub said in Voxl-mapper on VOXL2: @Zachary-Lowell-0 Does voxl-mapper need a TOF sensor to work properly? 1 Reply Last reply a day ago Reply @plub yes you need a modalAI tof for voxl-mapper to work properly - you can technically get by by using another TOF sensor but then youd personally need to write the code to popuilte the MPA with pointcloud data the the voxl-mapper client is subscribing to.

@Alex-Kushleyev I tested the ToF with another VOXL2 board I have. Modified the camera config as only for ToF. On ground tests, the camera server seems to work fine. On terminal system logger publishes similar type of CAM_INFO, CAM_ERR dmesg -w messages as earlier. We used the same interposer as used in earlier VOXL2 compute.