Posts made by shawn_ricardo

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!

Hi @Eric-Katzfey,

To start HITL, I used voxl-px4-hitl

I ran the commands:

1) qshell commander arm
2) qshell commander takeoff

which will eventually go into HOLD mode.

As far as the sensor positioning input, I'm assuming that I'm using GPS because I followed this instruction to turn off qvio:

NOTE: Ensure that voxl-qvio-server is disabled. If it is enabled, it will confuse gazebo due to gazebo sending fake sensor data to the qvio algorithm and causing poor flight dynamics in HITL. This can be done with the systemctl disable voxl-qvio-server command.

Here are the services running via voxl-inspect-services. Note that voxl-px4 is not running because the sim is not running:

Here is a readout of the qshell dsp_hitl status command, just to validate the connection:

The input was:

1. qshell commander arm
2. qshell commander takeoff

During the hold, the quad flipped.

Here is the PX4 flight log, which shows interesting actuator behavior:
https://review.px4.io/plot_app?log=518ccf49-36ed-4509-b928-da3dda44c7fd

The motor output diverges significantly around 2:12

At this time, the roll angle, pitch angle, and yaw angle executed deviated significantly from the commanded values:

Lastly, there were no failsafe flags indicating a loss of sensor input (e.g., EKF divergence, GPS loss, etc)....

[Only non-zero streams have been selected in the image below]

Could this be an issue with the actuation commands coming from the VOXL2?

Hello,

My platform:
Starling 2
hw platform: M0054
mach. var: 1.0.1
voxl-suite 1.4.3
system-image: 1.8.02-M0054-14.1a-perf
kernel: #1 SMP PREEMPT Mon Nov 11 22:47:44 UTC 2024 4.19.125

I've gotten Starling 2 HITL up and running according to https://docs.modalai.com/voxl2-PX4-hitl/. I can control the drone in simulation via RC and see video stream and control modes via QGC.

I am using this FTDI connection (https://www.amazon.com/gp/product/B07TXVRQ7V/ref=ox_sc_act_title_3?smid=AFLYC5O31PGVX&psc=1), where the JST GH is plugged into VOXL2 port J18. I made sure to not use the voltage, only TX/RX/GND.

The issue is that after takeoff, the quad almost immediately crashes by flipping or by suddenly executing some extreme acceleration. I'm not sure how to identify whether the issue lies in the simulation (e.g., latency, sensor input error) or in the drone commands and am hoping a dev may provide a next troubleshooting step.

Thanks!