Topics created by shawn_ricardo

@shawn_ricardo Hi!

To my understanding EKF2_EV_CTRL 15-->13 only remove EV from pos_z estimation, so it should be ok to do that if the range sensor is active. However, I did revert all parameters to the default settings (matching the VOXL-SDK definitions).

As my attempts to integrate the range-sensor data in altitude estimation did not seem to succeed, I decided to try and integrate the range-sensor in the VIO solution.
I created a version of the voxl-qvio-server in which pos_z estimation from VIO is replaced by the equivalent value based on the rangefinder:

s.T_imu_wrt_vio[2] = - down_range_m;

This seem to work better, however it is a workaround and not a full solution. My current experiments are performed in low altitude (~40-90 cm), so I am not concerned with the limited range of the rangefinder sensor.

I'm not sure what is the current implemented behaviour when EV estimation is not good, there should be some fall-back relying on the range sensor and imu. From my short experience with such cases of poor EV estimation mid-flight, the drone just crushes or jump to the ceiling with no control.

Any suggestions or further explanations will be much appreciated. Thank you

@shawn_ricardo ,

The hardware configuration for your application should be as follows:

J6 : tracking camera with either M0076 or M0135 interposer. Use J6L (lower camera port), which is the only port available on M0076 or JL port on M0135. This camera will be in HW Slot 0. J7 : Hadron, as described in the guide you already found. IR in HW slot 2, OV64B in slot 3 J8 : hires (any) camera. Use either M0076 or M0135. Use J8L (lower camea port). HW slot 4 note that J6U and J8U camera slots can only be used by the second stereo camera (in a stereo pair) due to custom I/O configuration that is default for VOXL2 varian 0 (which is what you have on Sentinel).

If you want to swap tracking and hires camera locations, you can just swap all the instructions as well 🙂

When connecting interposer and cameras, pay attention to pin1 orientaion, which is labeled on every camera connector, voxl2 connectors and interposers.

In terms of software setup:

back up (move) all sensormodule files from /usr/lib/camera/ copy the following sensormodule files that you will find in /usr/share/modalai/chi-cdk (i will assume that you are using imx214 hires camera): cp /usr/share/modalai/chi-cdk/ov7251/com.qti.sensormodule.ov7251_0.bin /usr/lib/camera/ cp /usr/share/modalai/chi-cdk/boson/com.qti.sensormodule.boson_2.bin /usr/lib/camera/ cp /usr/share/modalai/chi-cdk/ov64b40/com.qti.sensormodule.ov64b40_3.bin /usr/lib/camera/ cp /usr/share/modalai/chi-cdk/imx214/com.qti.sensormodule.imx214_4.bin /usr/lib/camera/

confirm the following are present in /usr/lib/camera/"

com.qti.sensor.ov7251.so com.qti.sensor.ov64b40.so com.qti.sensor.boson.so com.qti.sensor.imx214.so

Then, before updating /etc/modalai/voxl-camera-server.conf you can see if the cameras are detected:

voxl-camera-server -l

See output example here :

https://docs.modalai.com/debugging-camera-issues/#checking-which-cameras-are-detected-by-camera-server https://docs.modalai.com/debugging-camera-issues/#sensor-id-to-sensor-type-mapping

For camera server config, use the current config that you already have, wipe any cameras from it that are not tracking or hires. Then add the two camera entries for Hadron into your config, as shown here : https://docs.modalai.com/voxl2-hadron/#minimum-config .

You will need to make sure the camera IDs specified in voxl-camera-server.conf are correct:
0: ov7251
1: boson
2: ov64b
3: imx214

At this point everything should work, once you get here, I can help you customize the video streams as you need.

Alex

@Vinny

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

I tried to reproduce the setup from the windows PC

Wall power supply to Starling 2 (Same mains outlet) 12VAC to 5VDC to doodle labs radio 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)

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