Actually, can y'all provide the easiest path forward that supports just the tracking camera + hi-res front facing camera + FLIR Hadron?

That setup would be ideal

Hello,

On a separate VOXL2, I've got the FLIR Hadron 640R up and running using the hardware/instructions found in https://docs.modalai.com/voxl2-hadron/#flir-hadron-640r-support-on-voxl2-and-voxl2-mini

I want to integrate this camera on the Modal AI Sentinel platform, but see that J7 is occupied by what appears to be the tracking camera and possibly a hi-res sensor.

Currently, I don't require an occupancy grid, so its possible to disconnect both pairs of stereo-cameras on the Sentinel and free up those ports.

Can y'all provide assistance in either:

1. Disconnecting the stereo cameras (both hardware and software instructions) and configuring the hadron adapter on these newly available ports
2. Disconnecting the stereo cameras (both hardware and software instructions), reconfiguring the existing tracking camera / hi-res camera on J7 to a newly freed port? (so I can connect the Hadron to J7)
3. Some other method that you recommend?

Thanks!

@Eric-Katzfey

Okay, I'll keep this in mind as I develop toward offboard control. If I find any more information, I'll follow up here.

Just a side note: I don't see this behavior in real-world flight during manual or position, seems to be isolated to HITL at this point in time.

Thanks!

@Vinny

Really appreciate the in-depth response and thoughtfulness, your intuition was correct

I tried to reproduce the setup from the windows PC

1. Wall power supply to Starling 2
2. (Same mains outlet) 12VAC to 5VDC to doodle labs radio
3. Twisted D-/+ cables

Upon USB connection, I'm able to see the following on dmesg -w:

[ 1156.696173] usb 1-1: new high-speed USB device number 6 using xhci-hcd
[ 1156.832876] usb 1-1: New USB device found, idVendor=0424, idProduct=9e00, bcdDevice= 3.00
[ 1156.832886] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1156.848011] smsc95xx v1.0.6
[ 1156.912009] smsc95xx 1-1:1.0 eth0: register 'smsc95xx' at usb-xhci-hcd.0.auto-1, smsc95xx USB 2.0 Ethernet, 00:30:1a:3a:eb:c8
[ 1156.981572] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 1156.989474] QTI:Netlink Query to Kernel Success
[ 1158.456775] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 1158.464411] QTI:LINK_UP message posted
[ 1158.465167] QTI:Processing LINK_UP
[ 1158.465606] smsc95xx 1-1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x4DE1
[ 1158.472660] QTI:Enable mobileap
[ 1158.479629] QCMAP:Enable mobileap
[ 1158.598399] QCMAP:Enable mobileap done
[ 1158.602320] QTI:Setup TETHERED link
[ 1158.676632] QTI:LINK_UP Processed

and am able to stream data via voxl portal for a few seconds. Afterwards, the USB connection goes into a repeated disconnect/reconnect cycle.

Moving forward for next testing (and obviously final configuration), I'll power both from the same source (w/ a BEC), shorten the cables, and be sure to twist the data lines (similar to mcbl-0085)

Hi @Eric-Katzfey , would you happen provide further assistance on this issue?

My setup in summary:

1. 120VAC to 5VDC 3.1A Type A Female adapter --> Type A male cable to 6 pin JST GH where 3 wires are spliced from the hot wire into pins 1/2/3 on port 4 and 3 wires are spliced from the ground into pins 4/5/6
2. For connection to VOXL2, I have a JST GH 4 pin where pin1 is disconnected, pin 2 = D-, pin3 = D+, and pin4 = gnd. These connect to the corresponding wires for a USB 2.0 Type A Male to pigtails
3. The USB Type A Male from (2) is plugged into the Starling 2 USB port (where the ALFA adapter usually is) and dmesg -w continues to show error -71
4. The USB Type A Male from (2) is plugged into the USB adapter that comes with VOXL 2 USB3.0 / UART Expansion Adapter and dmesg -w continues to show -71
   • Not shown in the image (I have another separate VOXL2 board)

Here is an image of the setup:

This setup works repeatedly on Windows 11 PC. That is, the PC can ping the miniOEM doodle radio as well as a Wearable radio located several meters away.

Any next steps would be great, thanks!

Hi @Eric-Katzfey ,

I've tried those settings and the drone is able to stay hovering much long than expected. the positioning appears to be better, as well.

What service(s) might be getting in the way of HITL performance?

Also, I noticed during flight the drone vibrates significantly in HITL as soon as I publish offboard commands while in HOLD mode according to PX4's offboard guidelines. As soon as I stop publishing to /fmu/in/trajectory_setpoint, the vibrations stop. It is as if the drone is toggling between offboard and hold modes.

I have "offboard_mode" set to "off" in /etc/modalai/voxl-vision-hub.conf. I am running my own ros2 offboard node. I've enabled voxl-cpu-monitor, voxl-microdds-agent, voxl-modem, and voxl-wait-for-fs. I am running the deb package of voxl_mpa_to_ros2 . The command I am running is ros2 run voxl_mpa_to_ros2 voxl_mpa_to_ros2_node

I've tested the ability to publish offboard commands while in position hold mode in a completely separate px4 sim environment (just regular PX4 sim) and verified that drone position does not "vibrate" while offboard commands are being publishing and hold mode is the active mode.

What could be the cause of this behavior issue?

Per this post, I've tried the M0151 on another VOXL2 board w/ the USB to JST-GH cable. The doodle radio was still not showing up under lsusb

@Moderator , do you have any additional insight into what may be occurring here?

Hello,

There was a brief moment today when the device was working. Steps were...

1. Connect doodle labs radio to Starling USB port (the adapter)
2. Connect Starling to PC via USB-C
3. Power the doodle labs radio
4. Power the Starling 2

Upon entering shell, was able to see the default doodle labs ip address 10.223.0.100 on bash printout and was able to ping the doodle labs miniOEM radio and the wearable mesh rider radio

I configured QGC to point to the updated IP address and then started voxl-px4-hitl.

At this point, I realized QGC did not connect and upon further investigation found that the device was no longer seen via lsusb.

Is there any idea why the device would no longer be seen randomly or how I could troubleshoot this step?

@Eric-Katzfey , would you happen to recommend next troubleshooting steps?

Hello,

My platform is the Starling 2 and I am attempting to integrate the Doodle Labs mini-OEM 2023 Update.

I am supplying 5V at 3.1A via the 6 PIN JST GH connector and have a JSG GH to USB Type A cable, following this pinout

The setup works on a windows laptop:

1. miniOEM JST Port 1 connected via USB Type A to a windows laptop
2. configuration of windows laptop via doodle instructions
3. able to ping the miniOEM and a wearable Mesh Rider Radio ( the wearable is another separate physical device on the wireless network)

When I connect the same USB Type A port to the starlings usb port via the wifi adapter card (not the usb c port; where the Alfa network adapter is), a few things occur:

1. the device is not seen under lsusb
2. if the device is seen, voxl-configure-modem steps do not produce a valid eth0 port
3. if the eth0 port is created, the default ip address of 10.233.0.100 is not active

I'm unable to find support for this model of doodle labs radio. I believe the driver is included in the kernel (the doodle shows up as a LAN9500A USB 2.0 to Ethernet 10/100 Adapter), but I'm not certain.

Hoping a dev could point me in the right troubleshooting direction, thanks!