@Breanne-Crockett yes, the depth sensor is pointed straight forward We do not have support for Realsense

@lohithvamsi it is probably easiest to return Please reach out at https://modalai.com/contact and reference this post.

@jonathankampia , Have you checked that your Boson actually works (using a USB interface with either Flir GUI or a UVC interface)? Also, is your Boson configured to send MIPI data in 8-bit raw format? The camera server cannot change the FPS of Boson (or any of its streaming parameters). In fact there is no communication at all happening from VOXL2 to Boson (besides just probing / detection) - all the settings have to be configured by the user prior connecting to VOXL2 (including resolution, fps, etc). https://docs.modalai.com/M0153/#boson-software-setup Please double check these points.. Alex

@wilt From the production team, these should work for you: https://www.mcmaster.com/99461A923/

@Alex-Kushleyev Thanks for clarifying this!

@Taylor814 I would recommend starting the RMA process: https://www.modalai.com/pages/rma

In fact, I think the whole voxl-mavlink-server scheme to set the system time from the SYSTEM_TIME mavlink message is fundamentally flawed for the case when PX4 is run on SLPI. The SYSTEM_TIME message emitted from voxl-px4 uses the system clock of the apps processor as it's time basis. So essentially, it either never changes the system clock if the offset between SLPI monotonic clock and apps monotonic clock is less than ten seconds continually sets the clock to either the future or the past by the offset of the monotonic clocks in the case where the offset is greater than 10 seconds It seems like this system should really be based on GNSS clock time instead of the SYSTEM_TIME message for this setup.

@tonygurney See here for adb install instructions and debugging tips: https://docs.modalai.com/setting-up-adb/#setting-up-adb The udev rules at the bottom may solve your issue

@Jetson-Nano Can you please start a new thread for this new topic?

@wilkinsaf Yes this is definitely possible You would need to modify flow-server and possibly feature-tracker to ensure this is pointed at the right pipe Might also need a bit of calibration here and there Have not tested having multiple versions of flow-server, but should be possible. Would need to ensure this works with a downard facing tof for accurate height estimate To get a rough draft of this working, would take ~2 days

@Alex-Kushleyev would you be able to help troubleshoot this error with the rear tracking camera?

@cmall the VOXL 2 IO connects via UART. You could use any breakout board, like an Arduino, to generate PWM

@shawn_ricardo , just to close the loop on the original issue.. the delay in the calibration procedure was caused by UART data or processing of the ESC feedback backing up. The fix is to just slow down the command rate, seen in this commit : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/commit/b512f9e3d5e695868775de3d40eedb2ad15cf6d9 . Additionally, using command line argument --cmd-rate 100 when you run the calibration script on VOXL2 will fix the issue. Regarding the issue in the step response where the feedback data appears not smooth, i believe it is related to FTID's buffer / delay. FTDI adapters have this parameter latency_timer which is 16ms by default, which amount of time the FTDI board holds the RX'ed data before passing forwarding it to the PC (and vice versa, i believe). You can set that value to 1: You can check this value: cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer And set it: sudo su echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer You would need to do this every time you unplug / plug the FTDI device back in. (note that this applies only to Linux PC, not VOXL2). Besides this, i think the plots look good. It looks like you have set the kp pretty low, which keeps the response softer (less chance of de-sync). Alex

@victochen , just to close the loop on the original issue.. the delay in the calibration procedure was caused by UART data or processing of the ESC feedback backing up. The fix is to just slow down the command rate, seen in this commit : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/commit/b512f9e3d5e695868775de3d40eedb2ad15cf6d9 . Additionally, using command line argument --cmd-rate 100 when you run the calibration script on VOXL2 will fix the issue.

@Eric-Katzfey The update has been pulled into our fork now. You can access the updated package here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-px4_1.14.0-2.0.106-202507311432_arm64.deb