Dear ModalAI team,

We are in the process of finalizing the (ModalAI-powered) flight systems architecture for our upcoming projects, and would love to hear your thoughts regarding the same.

We are using VOXL2 (2X TOFs, 1 HiRes & 1 Tracking) as a OBC for high-level functions and Flight Core v2 for the low-level sensor interfacing and flight stabilisation running PX4. These are connected via UART and the voxl-mavlink-server is configured for external FC support. FlightCore is further integrated with 1x UART LiDAR, 1x CAN-based Optical Flow and 1xGPS (optionally)

While we understand that VOXL2 is capable of running PX4 on-board we found the HW interfaces to the DSP on the VOXL2 a bit limited in terms of adding new sensors like (UART Rangefinder and CAN-based Optical Flow). Additionally we enjoy a few small quirks like the ability to restart the PX4 independent of the whole board.

While adding Flight Core might initially feel a bit redundant in terms of available HW, we do eliminate the need for the IO Board entirely by going this route.

While we still await hard flight test data, the hopes of adding the Optical Flow sensor is to enable the MAV to sustain flight in Position-enabled modes until VIO recovers (instead of falling over to AltHold or other manual modes). The range-finder was added to enable accurate indoor flights, as we found the in-built barometer to have quite a bit of altitude offset and drift.

We would like to hear your views on whether the route we are taking is optimal and your recommendations on how to better suite your ecosystem with our requirements (the sensor setup mentioned above).

Thanks,
Kavin Kailash Ravie
UAVIO Labs

Dear ModalAI team,

I too am interested in understanding this better.

I understand that when using QVIO as the only source of localisation data, re-initialisation mid-air to base-coordinates would be quite dangerous, and hence not at all recommended.

But, in scenarios when the MAV is using QVIO data in conjunction with other localisation/odometry sources like GPS or HereFlow, Is there currently any way to configure the QVIO server to (re-)initialise itself based on the current EKF pose from PX4?

Thanks, for your quick response @Chad-Sweet .

We have already flight tested part of the setup above (except HereFlow), and it seems to work great.

Please find connection details in the attached picture below:

Dear ModalAI team,

We are in the process of finalizing the (ModalAI-powered) flight systems architecture for our upcoming projects, and would love to hear your thoughts regarding the same.

We are using VOXL2 (2X TOFs, 1 HiRes & 1 Tracking) as a OBC for high-level functions and Flight Core v2 for the low-level sensor interfacing and flight stabilisation running PX4. These are connected via UART and the voxl-mavlink-server is configured for external FC support. FlightCore is further integrated with 1x UART LiDAR, 1x CAN-based Optical Flow and 1xGPS (optionally)

While we understand that VOXL2 is capable of running PX4 on-board we found the HW interfaces to the DSP on the VOXL2 a bit limited in terms of adding new sensors like (UART Rangefinder and CAN-based Optical Flow). Additionally we enjoy a few small quirks like the ability to restart the PX4 independent of the whole board.

While adding Flight Core might initially feel a bit redundant in terms of available HW, we do eliminate the need for the IO Board entirely by going this route.

While we still await hard flight test data, the hopes of adding the Optical Flow sensor is to enable the MAV to sustain flight in Position-enabled modes until VIO recovers (instead of falling over to AltHold or other manual modes). The range-finder was added to enable accurate indoor flights, as we found the in-built barometer to have quite a bit of altitude offset and drift.

We would like to hear your views on whether the route we are taking is optimal and your recommendations on how to better suite your ecosystem with our requirements (the sensor setup mentioned above).

Thanks,
Kavin Kailash Ravie
UAVIO Labs

@Chad-Sweet Thanks for your response. I apologise for the late response. As you correctly pointed out, we resolved the issue after a re-calibration of the front stereo pair in natural lighting and by further tuning the 'blur_size' and 'post_median_size' parameters in the DFS server config file. Now the data reflects actual physical obstacles quite reliably.

Hello ModalAI Dev Team,

@Alex-Gardner @Chad-Sweet

We appreciate the great work done by the ModalAI team and look forward to more amazing feature rollouts.

While working on setting up the VOA utility packaged with the VVPX4 service, we noticed the presence of ‘ghost’ obstacles facing the front of the drone. We noticed this while inspecting the VOA linescan data from VVPX4 by running the following command:
voxl-vision-px4 -s
These erroneous data points seem to fluctuate around 0.25-0.30m and don't seem to respond to presence of any actual obstacle. We have double checked that the front stereo sensors are not obstructed by the airframe. Even while inspecting the OBSTACLE_DISTANCE MAVLINK message in QGC, we see the same behaviour in the data points.

In contrast, the data from the rear section of the VOA bin seem to correlate with our handheld obstacle tests. We attempted to flip the cameras from back to front (keeping in mind the R’s and L’s) and swapped the calibration (intrinsics) as well. But we still observed the same behaviour on the front sector of the VOA distance bin/linescan. It should also be noted that both the stereo pairs were re-calibrated recently.

We would be sharing more information regarding this as we collect more data, but in the meantime we would greatly appreciate it if you could assist us in debugging this behaviour.

HW Platform: VOXL2 with Front/Rear Stereo, HiRes and Tracking
System Image: VOXL2 Platform 0.9

Thanks,
Kavin