@Eric-Katzfey We are experiencing connection issues between VOXL2 and QGC.

QGroundControl is showing disconnected after inputting the comms link with 192.168.7.2:14550 in UDP. mavlink_to_gcs and mavlink_from_gcs are both reporting data. voxl-px4 and voxl-mavlink-server are running.

voxl-my-ip
192.168.7.2 (usb0)

@Alex-Kushleyev

Thank you for your continued support and assistance with this investigation.

Please find attached the system architecture diagram (power flow) of our platform for your review.

We would appreciate it if you could review the architecture and advise whether there are any potential concerns related to the power distribution, grounding scheme, wiring, connectors, ESC installation, or any other aspect that could contribute to the behavior we observed with the VOXL FPV ESC.

Additionally, we would like to highlight a few observations from our testing activities.

The abnormal ESC behavior was not present during the initial flight tests. The aircraft completed multiple successful flights before the failures began to occur. This leads us to believe that a direct short circuit caused by the frame, enclosure, or mounting arrangement may be less likely, as such an issue would typically manifest from the beginning of testing rather than after several successful flight cycles.

To further isolate the issue, we replaced the VOXL FPV ESC with a third-party NeutronRC X-CLASS 4IN1 ESC (70A). Following the replacement, the aircraft has been operating normally and has successfully completed multiple flight tests without any motor shutdown events or ESC-related failures.

At present, the third-party ESC continues to function correctly, and we have not observed any of the symptoms previously encountered with the VOXL FPV ESC. Motor operation, flight stability, and overall system performance remain normal.

This observation is particularly important because the remainder of the system configuration has remained largely unchanged, including:

VOXL2
Flight Controller V2
Power distribution architecture
Motors
Propellers
Battery configuration
Airframe and enclosure

Given that the issue is not reproducible with the third-party ESC, we are trying to better understand whether there may be any specific factors related to the VOXL FPV ESC installation, operation, thermal conditions, configuration, or hardware that could have contributed to the failures we observed.

For reference, the ESC installation includes:

An aluminum heatsink mounted beneath the ESC
Thermal interface material between the ESC and heatsink
Nylon spacers providing electrical isolation
A dedicated 3D-printed mounting structure preventing contact with the aluminum enclosure

Based on the current mechanical arrangement, we do not believe there is any direct electrical contact between the ESC and the enclosure.

We would greatly appreciate your guidance on any additional troubleshooting procedures that you would recommend for the VOXL FPV ESC, including:

Hardware inspections
Diagnostic tests
Additional logging parameters
Thermal validation methods
Power system checks
Known failure modes or common causes for the symptoms observed

If there are any specific measurements, logs, or test procedures that would help narrow down the root cause, we would be happy to perform them and share the results.

Thank you once again for your continued support and technical guidance.

We look forward to your recommendations on the next steps.

Thank you

70556136-f44a-4ea8-9bc3-80b63845a71c-image.png

@LukeNow This worked, thanks.

@JB1 Our voxl-remote-id software with WiFi dongle is intended only for reference and is not meant to be a commercially ready system for our customers who need a remote id solution for their VOXL2 based drone products. Integration, testing, validation, and FAA registration with desired hardware is up to the end user. At a minimum the manufacturer id would need to be changed from ModalAI's id to your companies issued manufacturer id.

@qubotics-admin , thanks for doing the motor swap test. From this result, it does appear that one of the ESC channels is not working properly. We would like to take a look at the ESC - are you able to send it back for inspection? We can send you a replacement ESC in return.

Alex

@ApoorvThapliyal : the problem (Error message: "set_position_target_local_ned: coordinate frame 0 unsupported") appeared in QGC after updating VOXL SDK from 1.5.0 to 1.6.3.
The error blocked me from being able to use QGC to calibrate or arm the drone. Stopping and restarting voxl-vision-hub solved the problem.
For now I'm using voxl-vision-hub as it comes on SDK 1.6.3 (no changes yet) and have not made changes to the .conf file (yet).

@vmbasvi That appears to be a Microhard modem, not a WiFi dongle.

@Ben-Linne : Thanks for the excellent instructions. Worked perfectly first shot. betaFPV is back to normal and binds to the radio controller ! Best regards, Hector

@jon When running that way make sure you wait a few seconds before restarting. If you ctrl-c out of voxl-px4 and immediately restart voxl-px4 you will see that error condition.

@bschulzhf PX4 will only correct incoming messages. Something external will have to also run TIMESYNC with PX4 to estimate the offset and correct and incoming PX4 message timestamps that it wants to align. voxl-mavlink-server does this for a few messages.

IMG_2112 (1) (1).jpg
IMG_2114 (1) (1).jpg

as you can see it has power as shown by the 5v LED but no other leds now light up?

@jameskuesel ,

I think there is another option which i have not considered before. The first three cameras are the same as above:

: M0173 J1: AR0144 slot 0 : CCI0 : M0173 J2: AR0144 slot 6 : CCI1 : M0173 J5: AR0144 slot 2 : CCI2

Then if we use J8U (which can be done using M0181 - it allows you to connect a Boson sensor to lower slot, and a tracking / hires camera to upper slot). Then the fourth camera would be:

VOXL2 J8: M0181 Upper : AR0144 slot 5 : CCI3

And there are no CCI conflicts.

One issue is that we don't typically sell M0181 by itself (only in a kit). Instead you could use two other options, both of which allow connecting a tracking / hires camera to the upper slot:

M0194 : https://www.modalai.com/products/m0194/ M0172: https://docs.modalai.com/M0172/ / https://www.modalai.com/products/mdk-m0172-1-00

The only down side of using M0172 / M0194 instead of M0181 is that the two alternatives do not have a mounting hole that would align with VOXL2 mounting hole, but M0181 does have a tab with a mounting hole for VOXL2 J8, see below. The M0172 and M0194 were really designed as mainly options for VOXL2 mini.

98d5f0ec-7f07-44bf-b002-036aefd3921d-image.png

c9c77086-b5fc-4215-99a2-fdc310d6f18c-image.png

@jon And you can find a lot of detailed information about the agent, including the start options, here: https://docs.px4.io/main/en/middleware/uxrce_dds

@awagner , I believe on VOXL2 Mini should be able to support any 4 cameras on the J6L, J6U, J7L, J7U (specifically the AR0144 (M0149) and IMX412 (M0107), which I assume you are using)

Can you please clarify the error that you are seeing? Is the issue the lack of correct sensormodule or something else? (you can check if correct sensormodules are present in /usr/lib/camera after configuring the cameras). As a reminder, the J6L, maps to slot 0, J6U, slot 1, J7L slot 2 and J7U slot 3.

Are you able to connect the 2 AR0144 cameras to J6 and J7?

What is your goal - how many of each cameras do you need to use? We can test it.

Alex

@nickanick Also, you can run voxl-mavlink-server with some of the debug options which will show you which packets are coming in and going out.

@Eric-Katzfey
Thanks for your reply! I am not attempting to establish communication via UART. I have already successfully been communicating the the FC/PX4 via WiFi, ethernet, and USB-C through the ADB shell (link). What I am talking about doing in my post is fundamentally different. I have an ELRS receiver plugged into J19 on the VOXL2. As mentioned in the above post, I have verified that the ELRS receiver/transmitter works for RC inputs over CRSF.

What I am trying to get working now is using the transmitter for QGC connection. This is possible on other flight controllers by connecting to the transmitter's local WiFi or via USB, but this does not seem to be working in the same way for the VOXL2. I imagine I am missing a specific configuration option or setting somewhere, or maybe this just isn't possible since Mavlink seems to be only communicated via UDP on this device. That is what I am looking for clarity on.

@Eric-Katzfey Currently the RFID reader connects to Jetson using a USB cable. We have API to access the RFID reader and read the RFID tags. We then process them in ROS2 nodes.

Does VOXL2 use Ubuntu Linux? Document also mentioned Docker. We should be able to load our docker image on VOXL2 as well.

My other concern is the bulkiness of the RFID antenna. It is 15 cm by 15 cm. I am wondering how we would be able to mount on the drone.

Mustafa

Doodle Labs radios are pretty plug and play with the VOXL2, I've been working with that setup for a while. The breakout board used in that guide is one supplied by Doodle labs in an evaluation kit, but you don't really need it. The breakout board and radio shown in the pictures also seem to be older models, so the pinout and connections today are slightly different. The software setup is still the same, using voxl-configure-modem.
With the VOXL2, you just need this cable:

https://docs.modalai.com/cable-datasheets/#mcbl-00085

and an add on board that has a 10-pin USB + power port such as this:

https://docs.modalai.com/m0151/

Then just connect the 6 pin cable to the mini oem's power port (port 4), and the 4 pin cable with the twisted wires goes to the mini oem's USB port (port 1), the mcbl-00085 link has some drawings. Then on the VOXL just run the configuration script. Also the radio can get hot pretty quickly so be wary of that.
If you're using a mini oem for the GCS side you don't really need that breakout board from doodle labs, you just need a 5V 2-3A regulator to power the mini oem on port 4, and there is a Rj45 ethernet adapter from Ark Electronics that matches the pinout of the radio's ethernet port, and I like to connect it to the mini oem's ethernet port (port 2) for my GCS device to use, but you can also just use a USB-A to JST adapter connected to port 1 instead.

@tom said in Latest SDK versions - How to access?:

https://storage.googleapis.com/platform-beta-releases/voxl2/voxl2_SDK_1.6.4-beta8.tar.gz

Thanks @tom !!!

So I'm guessing this has to do with the following I noticed in the changelog:

1.7.4
(voxl2_SDK_1.1.3)

BSP:

add voxl-fysnc-mod kernel module add voxl-gpio-mod kernel module
--- GPIO now exporting to /sys/class/gpio convert SE13 from 4W to 2W UART, freeing GPIO36/37 add voxl-platform-mod kernel module
--- see /sys/module/voxl_platform_mod/parameters add new target 'M0054-2' support (same rootfs as M0054-1) new kernel new devcfg.mbn

In system image 1.7.1 (SDK v1.1.2) on the drone that has no rc issues, recipes-kernel/linux-msm/files/dts/common/m0xxx-modalai-gpio.dtsi has:

&soc { b2b_conn_gpio_init { compatible = "modalai,voxl-b2b"; pinctrl-names = "default"; pinctrl-0 = <&tck22912G_ctrl_pin &b2b_pin7 &b2b_pin9 &b2b_pin17 &b2b_pin19 &b2b_pin38 &b2b_pin40 &hs_b2b_pin41 &hs_b2b_pin42 &hs_b2b_pin43 &hs_b2b_pin44 &hs_b2b_pin46 &hs_b2b_pin47 &hs_b2b_pin50 &hs_b2b_pin51 &hs_b2b_pin78 &hs_b2b_pin79 &hs_b2b_pin80 &hs_b2b_pin81 &hs_b2b_pin82 &j10_lvl_shf_ctrl_pin>; status = "ok"; }; rc_in_enable_init { compatible = "modalai,voxl-rc-in"; pinctrl-names = "default"; pinctrl-0 = <&rc_in_3v3_en_pin>; status = "ok"; }; };

In image 1.7.4 (SDK 1.1.3), recipes-kernel/linux-msm/files/dts/common/m0xxx-modalai-gpio.dtsi:

&soc { voxl_gpio { compatible = "modalai,voxl-gpio"; pinctrl-names = "default"; pinctrl-0 = <&tck22912G_ctrl_pin &b2b_pin7 &b2b_pin9 &b2b_pin17 &b2b_pin19 &b2b_pin38 &b2b_pin40 &hs_b2b_pin41 &hs_b2b_pin42 &hs_b2b_pin43 &hs_b2b_pin44 &hs_b2b_pin46 &hs_b2b_pin47 &hs_b2b_pin50 &hs_b2b_pin51 &hs_b2b_pin78 &hs_b2b_pin79 &hs_b2b_pin80 &hs_b2b_pin81 &hs_b2b_pin82 &hs_b2b_pin95 &hs_b2b_pin96 &j10_lvl_shf_ctrl_pin &rc_in_3v3_en_pin &ds2_led_red &ds2_led_green &ds2_led_blue &id_som_1 &id_som_2 &id_mai_3 &id_mai_4>; modalai,gpio-init-output-high = <0 1 53 56 57 85 86 87 88 89 124 152 157 159>; modalai,gpio-init-output-low = <36 37 46 54 55 67 82 83 84 131 153 154 155>; modalai,gpio-init-input = <48 49 50 51 52>; status = "ok"; }; voxl_fsync { compatible = "modalai,voxl-fsync"; pinctrl-names = "default"; pinctrl-0 = <&camera_sync_110 &camera_sync_111 &camera_sync_112 &camera_sync_113 &camera_sync_114>; status = "ok"; }; };

And then in image 1.8.06 (SDK v1.6.3) that is on the drone with the bind issues, recipes-kernel/linux-msm/files/dts/common/m0xxx-modalai-gpio.dtsi:

&soc { voxl_gpio { compatible = "modalai,voxl-gpio"; pinctrl-names = "default"; pinctrl-0 = <&tck22912G_ctrl_pin &b2b_pin7 &b2b_pin9 &b2b_pin17 &b2b_pin19 &b2b_pin38 &b2b_pin40 &hs_b2b_pin41 &hs_b2b_pin42 &hs_b2b_pin43 &hs_b2b_pin44 &hs_b2b_pin46 &hs_b2b_pin47 &hs_b2b_pin50 &hs_b2b_pin51 &hs_b2b_pin78 &hs_b2b_pin79 &hs_b2b_pin80 &hs_b2b_pin81 &hs_b2b_pin82 &hs_b2b_pin95 &hs_b2b_pin96 &j10_lvl_shf_ctrl_pin &rc_in_3v3_en_pin &ds2_led_red &ds2_led_green &ds2_led_blue &id_som_1 &id_som_2 &id_mai_3 &id_mai_4 &camera_sync_110 &camera_sync_111 &camera_sync_112 &camera_sync_113 &camera_sync_114>; modalai,gpio-init-output-high = <0 1 53 56 57 67 85 86 87 88 89 124 152 157 159>; modalai,gpio-init-output-low = <36 37 54 55 82 83 84 131 153 154 155>; modalai,gpio-init-input = <48 49 50 51 52 110 111 112 113 114>; status = "ok"; }; voxl_fsync { compatible = "modalai,voxl-fsync"; pinctrl-names = "default"; status = "ok"; }; };

So the gpio initialization process changed and rc_in_enable_init was removed between SDK v1.1.2 and v1.1.3, and between SDK v1.1.3 and v1.6.3, GPIO pin 67 got moved from modalai,gpio-init-output-low to modalai,gpio-init-output-high and GPIO pin 46 got removed from modalai,gpio-init-output-low.

https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/commit/538c324713548174c8c1694680e9cba7f2d47bcb

https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/commit/ccd3893e062b03d05885da5a279be2f8d2f6c97c

Idk which change is responsible for the binding issues. I'd like to avoid flashing v1.1.3 to narrow it down. Can someone explain how the pins are meant to function for my set-up (M0094 + M0054, rc already bound)?