@Benjamin-Ruks This shows that GPS has been selected as NONE so it won't try to set up the LED, magnetometer, or GPS. That will have to be changed to HOLYBRO. You can directly modify the file /etc/modalai/voxl-px4.conf to change that value.

@Chad-Sweet Hi Chad, I think I am into a trouble similar to Wenxi LiU. It appears to me that qvio server is enable and running but, when trying to check odometry in QGC or even with voxl-inspect-qvio, all the T_imu_wrt_vio(m) data is in 0 even when moving the drone. In QGC it appears the XY coordinates are in absolute 0 and Z with an offset os 10 meter, it appears to be a -10.9 coordinate while it hasn't moved at all. I tried to open the link you attached to the answer but the page is down. Is it another page or someone that could help me to troubleshoot this problem? Regards,

Please refer to the troubleshooting documentation https://docs.modalai.com/flying-with-vio/#troubleshooting-vio

@Chad-Sweet thanks. Is there also a datasheet doc for M0113?

You can find the document here https://docs.modalai.com/expansion-design-guide/

@Chad-Sweet Hey Chad! Yes 100% I'm open to the PC tools to get it done as well. I suppose I'm a bit uncertain about the hardware pipeline in this case. I'll want to have the traditional m500 ESC and motor, so I'll need to generate the PWM calibration curve somehow and generate the correct parameters. Should I use a surrogate m500 VOXL1 board to just get the values and run with those? -Joe

To conclude this post in the hope to help someone else who's having the same problem, I found this reply on another question in this forum which dates back to 2021. I guess the Relocalization still works only in Offboard and NOT in Mission. The same applies for an external flight controller e.g. in Ardupilot it works in Guided Mode and NOT in Auto.

@Kashish-Garg-0 Yes, everything in the aerospace industry including PX4 and ardupilot use the standard NED coordinate frame with Z pointing down. A significant portion of the code in MAVROS seems to be flipping the direction of the Y and Z axis back and forth when converting from mavlink to ros topics. I suggest using the vvhub_body_wrt_local pipe instead of the qvio pipe as the qvio data is centered around the imu whereas voxl-vision-hub transforms this to be centered around the body (COG) and corrects for gravity alignment. You can inspect the local pose on VOXL natively with voxl-inspect-pose vvhub_body_wrt_local OR voxl-inspect-pose --local Note this pipe was called vvpx4_body_wrt_local in SDK0.9 and older. I don't think ROS libraries like TF2 care which way gravity points. A transform is a transform, you can have it oriented however you prefer when you do your math. You should only need to change coordinate frames for the sake of visualization if RVIS doesn't let you define a default orientation or rotate the ground plane around in the UI.

@Sam-Kiley You'll want the standard M0117

@tom Thanks, I will try it

The code where quality is computed can be found here: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-qvio-server/-/blob/master/server/quality.h

Your sensors need to be mounted co-planar and rigidly like you see in our drone and flight deck products