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

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

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

@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

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

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

@Alex-Kushleyev Thanks mate!

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

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

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

@Rowan-Dempster Mainline PX4 now works on VOXL 2. It hasn't received that much testing yet but you are welcome to try it out.

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