@oiler251 You should be able to arm with the arm gesture (e.g. moving the left stick to bottom right). But since that isn't working I suggested to configure an arm switch. I do see that the RC2_TRIM parameter is set to 1000.0 which is odd. Normally it is around 1500.00. When you look at the QGC radio configuration screen and you move the sticks around do they look normal? And when sticks are centered are they all showing that they centered on the graphics? You could try setting RC2_TRIM to 1500.0 and see if that allows you to arm with the gesture. Please make sure you have the propellers removed when doing this testing!

@emarcphera Huh, interesting. Okay, thanks for posting the update!

@Vinny , I have the schematics ready for review. I will wait for your email to share them with you.

Regards and thanks in advance,
Fernando

Hi @Jetson-Nano
Here is our info for Doodle Labs support:
https://docs.modalai.com/cable-datasheets/#mcbl-00085
Sorry it's buried in a cable page, but it makes the case clear (we think) how to support Doodle 🙂
b1fa4a9a-f883-4566-b3e2-ae9ab14b7264-image.png

regarding probing USB signals, unless you had a USB decoder on the scope, I do not think that will prove anything useful. You may be better off running usbview:
Windows:
USBTreeView by Uwe Sieber — uwe-sieber.de/usbtreeview_e.html
It shows enumeration hierarchy, configuration descriptors, endpoints, VID/PID, power requirements, etc.
Linux equivalent:
Use usbview — it’s essentially the same utility (GTK front-end to lsusb).

Hope that helps!

@greg_s Great! Sounds good

@mkriesel , I have updated the boson configuration and read scripts (boson_read.py, boson_set_8bit.py, etc) to include configuring additional settings like mipi start state, dvo output interface, etc. Please download them again (from links earlier in this thread) and try again. Also, just to confirm that the original Boson setup instruction using the FLIR GUI should work for 8 bit format.

Just one note, even though I set myCam.dvoSetOutputFormat(FLR_DVO_OUTPUT_FORMAT_E.FLR_DVO_IR16), where FLR_DVO_IR16 = 3, when i read back the configuration, i get the default format (2) : FLR_DVO_OUTPUT_FORMAT_E.FLR_DVO_DEFAULT_FORMAT = 2 . It seems that in your output the ouput format is set to 3 - i am not sure why, there could be some minor quirks in the boson firmware.

In any case, please try the GUI and updated scripts and let me know how it goes!

Alex

Hi @will-huang-oksi
Are you willing to share some pics? Might be a cabling issue (GND loop or lack of a common GND), or some other intermittent connection causing your problems.
It really is hard to debug without seeing the setup.

Thanks!
Vinny

Here are the links to the test firmware:

M0129-3
M0129-6

After you update, you should see the following version after running voxl-esc-scan.py (except yours will be M0129-6). The firmware version will be 39.23 and this version will be reserved only for this test firmware:

INFO: ESC Information: INFO: --------------------- ID : 0 Board : version 40: ModalAi 4-in-1 ESC (M0129-3) UID : 0x2039333557555304003F0029 Firmware : version 39.23, hash 30c088dc Bootloader : version 184, hash 10bf24c8 ...

In case you need help updating ESC firmware: https://docs.modalai.com/voxl-escs/faq/#q-how-do-i-update-esc-firmware

We won't officially release this firmware version in order to avoid the aforementioned risk of turning on 5.0V by just installing a firmware update, however we will work on enabling this in the ESC params.

Also, just as a reminder, please be careful soldering to the AUX test points, use high quality flexible cables, and use strain relief to avoid lifting the pads.

Alex

@Moderator Many thanks for your reply

Our goal is to develop a drone capable of indoor/confined-space autonomous flight without GPS, using SLAM-based navigation. The system should perform 3D mapping, obstacle avoidance, and full-area path planning.

We would like to confirm the correct set of components and the required algorithm stack.

Planned Algorithm Stack:

State Estimation: QVIO (Visual-Inertial Odometry) providing position and velocity to PX4/EKF2 via voxl-vision-hub. Mapping: voxl-mapper (TSDF/ESDF) using a depth source. Planning and Avoidance: voxl-mapper’s path planner or PX4 avoidance, using VIO as the pose source. Autopilot: PX4 running on VOXL2 via voxl-px4.

Proposed Hardware:

VOXL2 Autopilot – https://www.modalai.com/products/voxl-2?variant=39914779836467 VOXL2 Tracking Camera (Mono Global-Shutter) – required for QVIO (please confirm the correct part number). -- https://www.modalai.com/collections/image-sensors/products/msu-m0149-1 VOXL2 Compatible adapter https://www.modalai.com/products/mdk-m0076-1 VOXL2 Time-of-Flight (ToF) Depth Sensor – https://www.modalai.com/products/m0178?variant=48528287793456 VOXL2 Mini 40-Pin Connector ToF Adapter (MDK-M0172-1-00) – https://www.modalai.com/products/mdk-m0172-1-00

Questions:

Please confirm if this set (VOXL2 + Tracking Camera + Camera adapter + ToF sensor + ToF adapter) is sufficient for robust indoor SLAM navigation using PX4. For the tracking camera, which exact ModalAI part number is recommended for QVIO on VOXL2? Are there any best-practice configurations for voxl-mapper when using ToF instead of stereo depth? Would you recommend any additional sensors for improved performance in larger or more complex indoor environments?

Goal Summary:
We want the drone to hold position, generate a 3D occupancy map, avoid obstacles, and autonomously plan paths throughout the flyable space—without any GPS input.

Thank you in advance for your guidance and confirmation.

Best regards,
Nitin

@Alex-Kushleyev

Thanks Alex, that did the trick I was able to get voxl-portal successfully up and running afterwards. The zoom slider works here too!

However, I still can't seem to get EIS to work. Unlike your demo, there is no side-by-side picture present when i inspect hires_misp_color in voxl-portal. I realized there was an "eis_view" parameter so tried both "pip" and "side-by-side" as listed in the tutorial but with no luck. It's still just the single picture.

Screenshot 2025-10-21 at 5.27.47 PM.jpg

Furthermore, nothing looks like its being stabilized. I am missing an easy gotcha somewhere in my config file? Here's mine its basically just the one from the tutorial.

/** * voxl-camera-server Configuration File * * Each camera has configurations for up to 4 HAL3 streams: * - `preview` stream for raw unprocessed images from CV cameras * - `small_video` 720p (ish) h264/h265 compressed for fpv video streaming * - `large_video` 4k (ish) h264/h265 for onboard video recording to disk * - `snapshot` ISP-processed JPG snapshots that get saved to disk * * on QRB5165 platforms (VOXL2 and VOXL2 mini) you can only have 3 of the 4 enabled * * This file is generated from default values by voxl-configure-cameras. * Do not expect arbitrary resolutions to work, the ISP and video compression * pipelines only support very specific resolutions. * * The default video compression mode is cqp or Constant Quantization Parameter * * * */ { "version": 0.1, "cameras": [{ "type": "imx412", "name": "hires", "enabled": true, "camera_id": 0, "fps": 30, "en_preview": true, "en_raw_preview": true, "en_misp": true, "preview_width": 4040, "preview_height": 3040, "misp_width": 1280, "misp_height": 720, "misp_awb": "auto", "misp_zoom": 1.5, "en_eis": true, "eis_mode": "horizon-level", "eis_view": "side-by-side", "eis_follow_rate": 0.01, "en_large_video": false, "en_small_video": false, "en_snapshot": false, "ae_mode": "lme_msv", "en_rotate": false, "misp_venc_enable": true, "misp_venc_mode": "h264", "misp_venc_br_ctrl": "cbr", "misp_venc_Qfixed": 30, "misp_venc_Qmin": 15, "misp_venc_Qmax": 51, "misp_venc_nPframes": 29, "misp_venc_mbps": 3, "ae_desired_msv": 100, "exposure_min_us": 25, "exposure_max_us": 15000, "gain_min": 100, "gain_max": 32000, "exposure_soft_min_us": 5000, "snapshot_jpeg_quality": 75, "small_video_width": 1024, "small_video_height": 768, "small_venc_mode": "h264", "small_venc_br_ctrl": "cqp", "small_venc_Qfixed": 30, "small_venc_Qmin": 15, "small_venc_Qmax": 40, "small_venc_nPframes": 9, "small_venc_mbps": 2, "small_venc_osd": false, "large_video_width": 4056, "large_video_height": 3040, "large_venc_mode": "h264", "large_venc_br_ctrl": "cqp", "large_venc_Qfixed": 40, "large_venc_Qmin": 15, "large_venc_Qmax": 50, "large_venc_nPframes": 29, "large_venc_mbps": 40, "large_venc_osd": false, "en_snapshot_width": 4056, "en_snapshot_height": 3040, "exif_focal_length": 3.0999999046325684, "exif_focal_length_in_35mm_format": 17, "exif_fnumber": 1.2400000095367432, "misp_venc_osd": false, "misp_gamma": 1.6, "ae_filter_alpha": 0.600000023841858, "ae_ignore_fraction": 0.20000000298023224, "ae_slope": 0.05000000074505806, "ae_exposure_period": 1, "ae_gain_period": 1 }], "fsync_en": false, "fsync_gpio": 109 }

If not, whats the best method to debug this? Again I'm on SDK_1.5.0 on a Starling 2 with the only upgrades being voxl-portal and voxl-mongoose (and all the changes/requirements from the tutorial (as far as I can tell)).

Thanks!

Hi @Martin-Lukac
Good catch on the pin swap. The Table is correct, with Pin 6 = GND.

The one thing I was wondering is related to this comment:
" I can power the ESC and the FCv2 separately."
That is not necessarily a good thing, and likely to lead to problems if you are powered up or down at different times. If one output (TX) is driving an unpowered input (RX), it could put the HW in a bad state. Please make sure to have them synced for ON and OFF.
Thanks.

@Rupesh Apologies for the late reply
It looks like there’s an issue with how the AprilTag system is relocalizing the drone. In my tests, the z-value appears to be misinterpreted, which could explain why your drone was climbing in altitude to correct its height estimate. We’re actively working on a fix.

Ok thanks, I can parse the raw data. I guess I was expecting the csv to contain the data as well

@SystemBrute . The problem has been solved.

Hi @QSL
OK, keep us posted!
Any, for any new issues, please be sure to start a new forum post so it is seen by the team.
Thanks!

@fhaltmayer It's not something we've explored

@Dmytro-Stolbovyi
voxl2:~$ usb-devices |less [1/1]

T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1
😧 Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev=04.19
S: Manufacturer=Linux 4.19.125 xhci-hcd
S: Product=xHCI Host Controller
S: SerialNumber=xhci-hcd.0.auto
😄 #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub

T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 5
😧 Ver= 2.10 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1
P: Vendor=0424 ProdID=2744 Rev=02.21
S: Manufacturer=Microchip Tech
S: Product=USB2744
😄 #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub

T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
😧 Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=0811 Rev=02.00
S: Manufacturer=Realtek
S: Product=802.11ac WLAN Adapter
S: SerialNumber=00e04c000001
😄 #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 6 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtl88XXau

T: Bus=01 Lev=02 Prnt=02 Port=04 Cnt=02 Dev#= 4 Spd=480 MxCh= 0
😧 Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0424 ProdID=2740 Rev=02.00
S: Manufacturer=Microchip Tech
S: Product=Hub Controller
😄 #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)

T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=10000 MxCh= 1
😧 Ver= 3.10 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1
P: Vendor=1d6b ProdID=0003 Rev=04.19
S: Manufacturer=Linux 4.19.125 xhci-hcd
S: Product=xHCI Host Controller
S: SerialNumber=xhci-hcd.0.auto
😄 #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub

T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 4
😧 Ver= 3.20 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1
P: Vendor=0424 ProdID=5744 Rev=02.21
S: Manufacturer=Microchip Tech
S: Product=USB5744
😄 #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub

T: Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=5000 MxCh= 0
😧 Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1
P: Vendor=2c7c ProdID=0801 Rev=05.04
S: Manufacturer=Quectel
S: Product=RM530N-GL
S: SerialNumber=4543cb18
😄 #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=(none)
I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)

@owf226 As soon as PX4 thinks it has taken off then it is trying to level the drone but can't since there are no propellers on the drone. So, it keeps increasing the speed of the motors on the side that needs to come up. That all seems normal to me.

@adiprin1 On Ardupilot there is currently no way to use apps side UARTs (Some day we will add a method to use them). So, you would have to use one of the 3 UARTs attached to the DSP. If you removed the RC or the GPS and used that port then, theoretically, it could work. However, we have not tried that so can't make any guarantees. Also on PX4 you can use an apps side UART if there is one available on an add-on board. And, as you mention, you could use an SBUS RC on the VOXL 2 IO board and free up the standard RC UART.

@tom Thank you very much for your information.