ModalAI Forum

@shawn_ricardo A couple of quick points. First of all, PX4 just queries the Linux system time so there's no mechanism to set a separate notion of system time in PX4. If the VOXL 2 is connected to the internet then, yes, it will update the Linux system time with NTP. But VOXL 2 has no battery backed RTC so if it cannot get system time from NTP then it uses the last saved time which is typically the last time there was a connection to an NTP server. Also, in newer versions of our PX4 we get rid of the -t option when starting the logger module so it will not use the system time. Instead it will just create session directories and log files within them in increasing numerical order. So, highest numbered log file in highest numbered session directory is the latest log.

Hi @shawn_ricardo Yes, any I2C port on an expansion board has 2.2K pullups to the voltage on Pin 1 of that connector. The Linux Kernel user guide has info on which QUPS are enabled or not in which system image. [image: 1769099579133-3356687b-6e2d-4443-9a15-6e9aa07566d1-image.png] and specifically this helps: https://docs.modalai.com/voxl2-qups/ Note not all QUPs have actually been enabled in the system, but with the sets of ports we have enabled, we never had any customer claim of a shortage:

@shawn_ricardo , just to close the loop on the original issue.. the delay in the calibration procedure was caused by UART data or processing of the ESC feedback backing up. The fix is to just slow down the command rate, seen in this commit : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/commit/b512f9e3d5e695868775de3d40eedb2ad15cf6d9 . Additionally, using command line argument --cmd-rate 100 when you run the calibration script on VOXL2 will fix the issue. Regarding the issue in the step response where the feedback data appears not smooth, i believe it is related to FTID's buffer / delay. FTDI adapters have this parameter latency_timer which is 16ms by default, which amount of time the FTDI board holds the RX'ed data before passing forwarding it to the PC (and vice versa, i believe). You can set that value to 1: You can check this value: cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer And set it: sudo su echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer You would need to do this every time you unplug / plug the FTDI device back in. (note that this applies only to Linux PC, not VOXL2). Besides this, i think the plots look good. It looks like you have set the kp pretty low, which keeps the response softer (less chance of de-sync). Alex

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