Hi @Jetson-Nano,

Can you please clarify the following - in your original post, you mentioned that the third party ESC also had issues, however in the post above you said no issues. I am quoting your notes from above:

"
Scenario 3 – Third-Party ESC Evaluation
To further isolate the issue, we replaced the VOXL FPV ESC with a NeutronRC X-CLASS 4IN1 ESC V2 (3–8S, 70A) configured using the DShot protocol.

During testing, we observed the following:

ESC temperature increased rapidly, reaching approximately 80°C to 90°C within two minutes of flight.
One motor would subsequently stop during flight.
The aircraft would lose stability and crash.
"

I just wanted to clarify what actually happened and then we can investigate further. Than, you for providing the diagram, i think it looks OK.

I have never seen this behavior where the ESC reports incorrect voltage and these short spikes in temperature. This may point to a hardware issue on the ESC board, but i do not actually know where it might be or what would cause it. Have you visually inspected the FPV ESC that has this issue to see if any components appear damaged or anything looks unusual?

Alex

@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

@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.

@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.

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?

@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)

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.

@nl_vdi , if you log into developer.modalai.com, you will see the CAD models. the latest model we have is:

D0012-4-V3-C28-M36-T7-K0-Starling2-Max-V3-20260317.step

376bf0dd-494a-4bf1-8d92-1b2d91afb83d-image.png

@Eyal ,

I will look for an indoor flight log from a stinger. At hover, the power usage should be around 110-115W based on motor dyno tests. The peak motor current can go up to 300W (per motor), but it's not possible to have all 4 motors maxed out.

Regarding ethernet.. It is actually possible to establish a full wired interface using the same usb interface that is used for ADB. it is a lot more efficient that using something like adb port forwarding. We have some scripts that set up the full network with NAT, when voxl2 / voxl2 mini is connected to a linux host. There is one script that enables the usb ethernet in voxl2 kernel and then there is the host side script to set up the networking and tcp/ip rules for NAT (so that voxl2 can access internet via the host) -- the NAT part is actually optional.

Actually the first part (without NAT) is already documented here, you could try it : https://docs.modalai.com/qgc-via-adb/ -- this will give you a full tcp/ip connection to the linux host.

For downloading log files, we get about 35-37MB/s, it seems to be a 400Mbps link. Even with 1Gbps usb3 adapters we don't get full 1Gbps, so this may be the best you can get. Can you clarify your application for the network connection?

Alex

@cguzikowski ,

Sorry for the delay.

Regarding the new HW not working, since you have two identical setups, i would recommend swapping components to identify what exactly is not working. This is the most efficient way to diagnose it. From the logs you provided, the ov64b camera is detected and initialized, it seems, but no frames come in, which could be a cabling or interposer issue.

I will get back to you with an update on the lens shading tomorrow.

Alex

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)?

@Vinny Can you explain how the J10/J19, M0094 and the spektrum receiver are meant to work together?

I have a dev drone w/ VOXL2 & spektrum satellite receiver. After flashing the latest SDK (1.6.3) the receiver and transmitter stay bound but I have to force a rebind to get RC data coming in to PX4 every time I power cycle the drone. No issue up to SDK 1.1.2 and I noticed the way kernel GPIO initialization is handled changed in 1.1.3. More details here:

https://forum.modalai.com/topic/5243/spektrum-rc-bind-issues-after-sdk-update

I'm guessing this has to do with GPIO pin settings for pins 46, 67 or 159 being set wrong on boot, but I don't know enough about the hardware to understand what's going on. If I have a spektrum receiver on a dev drone w/ M0054 that is already bound to a transmitter, what should the GPIO pin settings be on boot to enable rc data flow to px4?

Hi @bschulzhf

You need to copy the new sensormodule file with the correct slot id (number at the end) to /usr/lib/camera and (re)move the existing one, so that it does not get picked up by the camera pipeline.

Good idea to back up your existing configuration before making changes.

Also more general details here : https://docs.modalai.com/configure-cameras/#connect-a-new-camera

Alex

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

@Alex-Kushleyev

At a bare minimum I just need the additional pwn channels to be controlled by joysticks via QGC. They don't need to be connected to PX4/Autopilot at this point. Does this allow for an easier solution?

Thanks!
Matt

@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 !!!

Hi @RoyAzriel ,

Running voxl-inspect-cam -a puts significant stress on VOXL2 as all possible camera streams are generated and sent out to the voxl-inspect-cam application. With a small number of camera or low resolutions this can work fine, but in C29 config, this is not a sustainable test. There are quite a few very large images (4056x3040) per hires camera that are being sent uncompressed, causing a lot of cpu stress.

A better test would be to first run voxl-list-pipes to see which camera pipes are available and then run voxl-inspect-cam with arguments explicitly listing the camera streams to inspect -- ideally choosing one stream per camera.

example : voxl-inspect-cam tracking_front tracking_down hires_front_misp_color etc.

So to answer your question regarding "I wonder how it works well when you ship out C29 from the factory" -- we do not use voxl-inspect-cam -a for testing for the exact reason i described. Single stream per camera verification (can be simultaneous for all cameras) is sufficient to test the camera pipeline.

When voxl-inspect-cam was originally developed, we did not have as many cameras connected and the test worked fine, but started hitting system limits as the number of connected cameras (and their resolution) increased. In reality, you would never have to ship such large images across processes -- there is a better mechanism for sharing large buffers between processes (ION buffer) which avoids sending huge amounts of data over the linux pipes. ION buffer sharing is supported on voxl2 but that is outside of the context of this discussion, i believe 🙂

The rotation of the PMD sensor is done in software (camera server config, look for the rotation param) and it is done to match the actual rotation of the sensor in the camera mount. You can disable rotation in the camera server config.

Alex