Is there a paper or documentation on the overall performance of the qvio machine vision algorithm shipped with the VOXL compared to other off-the-shelf algorithms/hardware?
Examples of what I would like to compare it to:
Came across this commit in the voxl2 bsp source tree: https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/commit/944b83b80a3633f684ae8abdcd2357cfbde16a26
What is this fix addressing? Is there some potential instability on the existing power supply config for voxl2 bsp versions pre-dating this ? In my own work, we've occasionally seen the front facing imx412 sensor either a) drop out or b) seemingly not start correctly on a couple of our starling platforms. Just wondering if this might be related?
Hi @tom just an update after the weekend. Sort of surprisingly, we cannot now recreate the SLPI error on the boards. Both with and without the voxl-px4 service enabled, both boards are booting up and staying alive.
We've done a couple boot cycles with voxl-px4 enabled and things seem stable. We are putting these boards into a larger enclosure and so I'll wait till the team tests that to declare victory 
Just out of curiosity, is it a Modal SDK process that was triggering that board reboot before, or something lower level?
@tom for the boards we tested, we tested one fresh out of the package with nothing else connected and this error. The other, we tried different combinations of cameras plugged in, along with nothing plugged in, and still saw this.
On the question of whether this goes away when disabling and stopping voxl-px4 service, we did try this once but still saw the issue. However, the time we tried it we did not give the “sync” command after stopping the service. But we did give the systemctl stop and saw the error happen right after. There’s only a window of about 30 seconds after boot to get in and give any command, it’s a bit tricky.
Could completely reflashing starting with the qdl tool be an option here?
@viralp for visibility
Sure, I will check and send the information. Strangely, we actually ordered 3 and a second of the three is also having this issue. The third is working fine.
I've got a fresh Voxl 2 board which I powered on for the first time. The board powers on and seems to start in a good state, but some 26seconds after boot the device is crashing and reporting some slpi error with px4.
@tom That qdl reset did the trick, thanks!
Yes, SW2 is in "off" state, so looks like voxl 2 is bricked. I'll try out the qdl instructions and come back with updates.
Output from lsusb when voxl2 has been placed in fastboot mode:
mb@mb-HP-EliteBook-840-G7-Notebook-PC:~/Downloads/voxl2_platform_0.9$ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 017: ID 18d1:d00d Google Inc.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 06cb:00df Synaptics, Inc.
Bus 001 Device 002: ID 04f2:b6bf Chicony Electronics Co., Ltd
Bus 001 Device 004: ID 8087:0026 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Lsusb after the flashing and while the script waits for adb to come back up
mb@mb-HP-EliteBook-840-G7-Notebook-PC:~/Downloads/voxl2_platform_0.9$ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 018: ID 05c6:901d Qualcomm, Inc.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 06cb:00df Synaptics, Inc.
Bus 001 Device 002: ID 04f2:b6bf Chicony Electronics Co., Ltd
Bus 001 Device 004: ID 8087:0026 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
dmesg output for fastboot mode:
[755391.801828] usb 2-1: new SuperSpeed Gen 1 USB device number 17 using xhci_hcd
[755391.823072] usb 2-1: New USB device found, idVendor=18d1, idProduct=d00d, bcdDevice= 1.00
[755391.823082] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[755391.823087] usb 2-1: Product: Android
[755391.823092] usb 2-1: Manufacturer: Google
[755391.823096] usb 2-1: SerialNumber: 9ce13470
dmesg for after fastboot, while waiting for adb to become available:
[755509.829081] usb 2-1: new SuperSpeed Gen 1 USB device number 18 using xhci_hcd
[755509.856499] usb 2-1: New USB device found, idVendor=05c6, idProduct=901d, bcdDevice= 0.00
[755509.856508] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[755509.856513] usb 2-1: Product: QUSB_BULK_SN:A07D5C7A
[755509.856517] usb 2-1: Manufacturer: Qualcomm CDMA Technologies MSM
[755509.856520] usb 2-1: SerialNumber: 9ce13470
The instructions on the documentation for re-flashing the system image on the voxl 2 doesn't quite match what the latest scripts from the voxl2 platform 0.9 image tar provide. The package provides an "install.sh" script as the entry point for re-flashing. The instructions mention there should be a "flash-full.sh" script.
Assuming the above is supposed to be the correct script, I did try putting my voxl 2 into fastboot state and running the install script. It was able to identify the partition and reset the board, but it hangs at the "Waiting for ADB" step. The voxl 2 is showing up in dmesg as a Qualcomm device, but adb doesn't show it as available, hence it hanging at the waiting for adb step.
Any ideas on what to try?