@Jeremy-Frederick , If VIO is working, then there is a very high chance that you got the orientation correct . If the camera to IMU orientation is off by something like 90 degrees in any direction, VIO is pretty much guaranteed to fail. So if you are getting normal VIO performance, quick initialization, across multiple tests, then I would say that your orientation parameters are correct for VIO. Please keep in mind that if you flipped the board and if you are planning to fly with PX4, you will need to change the imu rotation params in PX4 (also keep in mind that PX4 is using a different IMU that is connected to the DSP)

@Adriano-Del-Pino-Lino Please reference this other post: https://forum.modalai.com/topic/3341/odometry-message/2

Yes you can look at it that way. Pose is just the generic positional data inclusive of the quaternion and imu wrt vio/camera - odometry is that as well as things like the twist or better known as velocity wrt to the vio instance/camera and the angular velocity wrt to the vio/camera. Let me know if this better helps you understand - all the code is open sourced btw so feel free to take a gander for a programatic understanding: https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-to-ros2/-/blob/master/colcon_ws/src/voxl_mpa_to_ros2/src/interfaces/qvio_interface.cpp?ref_type=heads#L113

@Alex-Kushleyev Thanks mate!

@ptaylor1234 Did you get it working, I am also working on a similar one

@AP123 Hi, I have not seen this before, but I also haven't tried enabling obstacle avoidance. I can't pretend to know much about the obstacle avoidance code running inn the VOXL SDK, but I suppose this error could be caused by some obstacle avoidance service not running on the VOXL when it should be, hence QGroundcontrol being confused.

@SMRazaRizvi @madswamp @Jgaucin @AndriiHlyvko @camharrisvayu Hey all, apologies on this. We were finally able to recreate the issue but unable to determine what the root cause was. Regardless, we have a new SDK (1.1.0) released which isn't showing the stack smashing issue. https://developer.modalai.com/asset/2 Please let me know if this is still an issue and sorry for the wait on this. Thanks, Thomas Patton

@tom SOLVED, thanks Tom, that command line prompt showed me that I needed to voxl-configure-extrinsics. Thank you!

@david-moro That is my impression too, that and, it does not seem to be all that robust in general. I am very interested in using an open source VIO solution, and build it to be a mostly drop-in replacement for Qvio. I need it for high-altitude flight too, in mostly texture-less environments, a most robust solution seems necessary. I only just started looking into which methods could be interesting to use, and came across DM-VIO: Delayed Marginalization Visual-Inertial Odometry which seems to be very modern and robust. The paper for this states that it was run in real time on a 2013 mobile i7 at 2.3GHz, so I am hopeful that it could run on the VOXL 2. I would be interested in following along if any of you decide to go in another direction than Qvio.

@Moderator will try to on our next flight. Do you have an easy way to trigger a capture when certain conditions are met? It is hard to correlate hundred of images to the autopilot logs to find these instances. We are working on streaming the qvio-overlay as an RTSP stream down to the GCS. That might be easier. Unrelated question. Can the VIO algorithm use the colored images coming from the camera? If yes, is there an advantage at all?

Thank you. I got the VIO going on the drone. I noticed that when running the VIO server, the IMU_BW error kept coming up and that was the cause of the server's crash. Therefore, I increased the limited_imu_bw_trigger parameter in the voxl-qvio-server.conf arbitrarily to 100 and it worked fine.

You can't really tune the feature detection algorithm. You can tune the exposure algorithm. You might try to increase ae_msv parameter in camera-server config to maybe add more contrast?

@Steve-Turner Thank you for your help. I realize you are not part of the ModalAi Dev Team, but I would like to ask for your help with this. There is more information that I have posted on this thread. I am lost, and would really appreciate any kind of help you could provide. Thank you.

@Steve-Turner - Yeah I have put EKF2_AID_MASK to 0. Then the drone would just be behaving normally. @Cliff-Wong - I understand that I would have to disable qvio-server, if I would only fly in non-evdata modus. But when flying with evdata, if then the evdata goes bad, I need to switch to non-evdata to be able to save the drone from crashing. But now the drone will still crash!

Hi @Matt-Turi, Thank you very much for your clear answer. We will give this a try! If you have any examples or more information on how to do this, please feel free.

Anything with visual texture will improve performance. It does not have to be an AprilTag. Just anything with a non-repeating pattern