@Jetson-Nano , since we currently have no plans to do the MIPI integration of this sensor, you always have the option to use USB connection and voxl-uvc-server to publish images via MPA. You would need to check if the sensor supports the standard UVC interface and try it out... Alex

@greg_s That would explain a lot what's happening. If you start fresh and connect to the drone with voxl-portal and goto the VIO tab/menu option, you should be able to pick up the drone and perform a bench test. Considering Figure 8 is not working, you will need to inspect the front and downward camera, tighten/remount any loose parts and possibly check camera focus & calibration. Worse case if the forward camera is good and not changed from factory, you can edit /etc/modalai/vio_cam.conf on the drone and disabled the faulty camera (disabled the down camera). You'll have degraded precision (mainly bad vio in fast yaw motions), but should be able to perform a figure 8 and should get you running until you repair that bottom sensor.

@Alex-Kushleyev Thank you so much! I'm a bit preoccupied with a few other projects but hopefully I can take a look by the end of next week and get back to you.

@jh81306 Hello there, Yes, real time performance is achievable with 3 cameras at 30fps, evidencing the benefits of our hardware accelerated GPU feature tracker. From this perspective, if you plan on using GPU-heavy applications, QVIO may be the second best option, as it uses remote procedure calls between the linux processor and the DSP, freeing GPU usage. However, due to the inherent nature of the DSP (L2 Cache, etc) and timing considerations, running QVIO on 3 Cameras may not guarantee a consistent update rate depending on the processor load/scheduler priorities. In essence, choosing one or the other is a trade-off that should be based on user use-case. In terms of estimator robustness, our branch of OpenVINS has been considerably modified to support accurate estimates under degraded conditions, and all ModalAI UAV platforms have gone through extensive calibration in order to obtain the optimal parameter set. Hence, in terms of estimator quality, OVINS outperforms QVIO, but requires carefully calibration of your visual-inertial sensors. Finally, If you opt to acquire a ModalAI Vision drone, OpenVINS should be fully functional out-of-the-box, facilitating a potential pipeline transition.

@Catalystmachine , for questions regarding orders, please reach out here : https://www.modalai.com/pages/contact-us

@Catalystmachine https://www.modalai.com/products/m0155 https://www.modalai.com/products/m0188 (fixed link) https://www.modalai.com/products/m0194 If you need M0195, you can contact us directly for a custom order (it's not in the shop yet). https://modalai.com/contact Alex

@Dan-Jennings , M0181 can be used to enable a Boson and another hires or tracking camera (or Hadron combo), see diagram below. You would need to use the kernal variant 1.0.1 (same one used for M0173, which I am assuming you are already using). So basically, you can use any standard config C26-C29 + two more cameras connected to VOXL2 J8. Please note that VOXL2 J8 shares CCI (i2c) buses with J6 and J7, so you have to be a little careful about what cameras you connect to J8 to avoid i2c address conflicts. I am going to put together some more information on that soon. But if you are adding a Hadron or Boson + IMX412 to J8, there will be no conflict. Please let us know if you have any other questions. Alex [image: 1771605639258-voxl2_m0181_boson_hires.png]

Hi @DavidTorres, Thanks a lot for the detailed explanation — this is very helpful. Your comments about VIO drift, autonomy limitations, and the development effort required give us a much clearer picture. We’ll review the documentation and PX4 resources as suggested. Thanks again for taking the time to share your experience. Best regards

@Alex-Kushleyev I made the following changes. Modified the DTS files as stated prior. Flashed the devcfg.mbn file from SDK 1.0.0 I did not need to configure the level shifter actually. The port worked in SPI mode even without running voxl-gpio -w 67 1. Running the command doesn't seem to change anything. I used Channel 1 on /dev/i2c-0 for the second lepton. I simply wrote TCA9543A_CHANNEL_1_ENABLE to TCA9543A_CONTROL_REGISTER in voxl-lepton-server. I pretty much followed what was described here.

Carson— I'm trying to do the same: create a Kicad symbol for VOXL 2 as a module (ie, no internal details, just interfaces). Have you had any luck in locating something? Best, —John

@joshuagaus Sorry, but SBUS is not supported. That option will be hidden in future SDK releases to prevent confusion.

@Myles-Levine Nevermind, I got it working through the voxl interface instead of Qgroundcontrol. Thank you.

@Eric-Katzfey And this is also handy: https://www.sparkfun.com/breadboard-to-jst-ghr-04v-cable-4-pin-x-1-25mm-pitch.html

@jon For MONOTONIC the apps side uses the slpi version so that they are in sync. Your application should use apps MONOTONIC. PX4 will convert it using timesync.

@Moderator Thanks for the quick response! Which helper would you recommend for outdoor flight configuration with GPS? I see there are several available for different variations. An added detail: we need good relative altitude measurements at low altitudes for our custom precision landing solution.