Hi @Eric-Katzfey @Alex-Kushleyev , would y'all be able to answer the questions above?

Just to recap, I ordered the Starling 2 and the default PX4 parameters shown via QGC have pretty much everything but vision sensor input turned off. As far as I know, the Starling 2 comes with a GPS (no mag) and downward facing distance sensor. Both could be used as sensor input sources into PX4s EKF. So, I'm curious if y'all use those sensors as input into your VIO implementation as a sort of upstream sensor fusion. In which case I can leave those PX4 parameters as is

Re: Running VIO with GPS active

Hi @Cliff-Wong ,

Following up on your reply in the post "Running VIO w/ GPS Active". I am flying a Starling 2 and have been unable to conclude how Modal handles various sensor input streams to PX4.

I see that the Starling 2 has a downward distance sensor, VIO, and GPS (in addition to IMU). This is where the confusion begins because I also see that default Starling PX4 parameters only have Vision enabled for heading, velocity, and position via EKF, that GPS is disabled & set to not exist, and that downward lidar sensor input is disabled.

Does the VOXL perform some sort of sensor fusion on these input sources, then send the output of fusion to PX4 through the vision topic such that vision encompasses GPS, downward distance sensor, and VIO? Or is it the case that the sensor streams other than VIO are actually ignored by PX4 and/or not sent by default (in which case I can simply enable the sensor input and update EKF parameters).

Could you provide more clarity and maybe any recommendation on how I could leverage the sensors in PX4?

@Eric-Katzfey

Would you be able to point me in the right direction? Maybe a list of technical docs or something of the sort?

Thanks!

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?