@Will , i still have not been able to reproduce the issue but I may have found a very rare condition that may be happening in your case. I am going to share a firmware update soon and ask you to test it if possible. thank you
@Eric-Katzfey that was a good question. today I setup my bench to run the px4 version in sdkv1.1.1 and at first I was unable to recreate the problem.
After further testing I noticed the behavior happening when we would upload our qgc param file from the previous version. My co-worker and I spent some time and isolated the parameters that were the problem children. For what ever reason the parameters below when uploaded via a QGC file is causing the problem
I then set the bench back to the stable sdkv1.1.1 version and created a parameter file with only the parameters above and I was able to see the same problem.
Steps to recreate
make sure you run all commands over ssh and do not create an adb session.
load stable version of px4. (voxl-px4_1.14.0-2.0.59_arm64.deb)
remove old parameters by running rm -rf /data/px4/param/*
run voxl-px4 once to set the parameters back to default
make sure sbus receiver and controller are powered on and connected.
open up QGC and the problem should be visible
I honestly have no Idea why uploading these params in particular break px4. we were able to upload all the other params in the file just fine.
We did discover a work around. If we upload all our old params but the ones listed above and then configure them via QGC the problem does not present itself. The super weird thing about this is that I can then download the parameters and diff them vs the old ones and the above parameters will show as identical.
Also I can not explain why connecting to the voxl with mini-dm once per boot resolves this issue. I did do further testing on though. It seems like if you open up an adb shell it also resolves this issue similar to using mini-dm, which i guess mini-dm works via adb so its probably the debug link that fixes this problem.
We are able to continue testing using our work around, but I would be very interested to see what the root of this issue is. Let me know if you all are able to recreate and or if you need more information.
EDIT: It all works! I think I have a better understanding of how things work now? When I was only detecting one camera, the camera was on the upper connector and I had to have it as the first camera in the config for it to work. When I re-seated the cable and could detect two cameras I had to have the first cam in the config be the tracking one from the lower connector and the hires be on the upper. Now it all works. Thanks for the help!
@Nathan-Raras Now after a few reboots and changing things I'm detecting the hires, but no tracking, but it's not crashing.
I'm just going to put my voxl-camera-server.conf file here, and the binaries that are in /usr/lib/camera.
voxl2-mini:~$ ls /usr/lib/camera/
com.qti.eeprom.cmk_imx577.so com.qti.sensor.ov7251_front_left.so com.qti.sensor.ov9782_front_right.so
com.qti.sensor.ar0144.so com.qti.sensor.ov7251_front_left_flip.so com.qti.sensor.ov9782_front_right_flip.so
com.qti.sensor.cmk_imx577.so com.qti.sensor.ov7251_front_right.so com.qti.sensor.ov9782_rear_left.so
com.qti.sensor.cmk_imx577_flip.so com.qti.sensor.ov7251_front_right_flip.so com.qti.sensor.ov9782_rear_left_flip.so
com.qti.sensor.imx214.so com.qti.sensor.ov7251_fsin.so com.qti.sensor.ov9782_rear_right.so
com.qti.sensor.imx214_flip.so com.qti.sensor.ov7251_fsout.so com.qti.sensor.ov9782_rear_right_flip.so
com.qti.sensor.imx335.so com.qti.sensor.ov7251_rear_left.so com.qti.sensormodule.imx214_3.bin
com.qti.sensor.imx377.so com.qti.sensor.ov7251_rear_left_flip.so com.qti.sensormodule.ov7251_2.bin
com.qti.sensor.imx678.so com.qti.sensor.ov7251_rear_right.so com.qti.tuned.cmk_imx577.bin
com.qti.sensor.imx678_flip.so com.qti.sensor.ov7251_rear_right_flip.so com.qti.tuned.cmk_ov9282.bin
com.qti.sensor.imx678_mod.so com.qti.sensor.ov9782.so com.qti.tuned.default.bin
com.qti.sensor.irs1645.so com.qti.sensor.ov9782_front_left.so com.qti.tuned.sony_imx335.bin
com.qti.sensor.ov7251.so com.qti.sensor.ov9782_front_left_flip.so components
voxl2-mini:~$ cat /etc/modalai/voxl-camera-server.conf
* voxl-camera-server Configuration File
* Each camera has configurations for up to 4 HAL3 streams:
* - `preview` stream for raw unprocessed images from CV cameras
* - `small_video` 720p (ish) h264/h265 compressed for fpv video streaming
* - `large_video` 4k (ish) h264/h265 for onboard video recording to disk
* - `snapshot` ISP-processed JPG snapshots that get saved to disk
* on QRB5165 platforms (VOXL2 and VOXL2 mini) you can only have 3 of the 4 enabled
* This file is generated from default values by voxl-configure-cameras.
* Do not expect arbitrary resolutions to work, the ISP and video compression
* pipelines only support very specific resolutions.
* The default video compression mode is cqp or Constant Quantization Parameter
@SMRazaRizvi You have to setup GPS and make EKF Aid mask use GPS, and I don't think using GPS will give you odometry data, you might get some sort of global position which helps you hold position and navigate
@Anubhav No, the Qualcomm Flight RB5 Reference drone uses the Thundercomm QRB5165 SOM. The Sentinel has the same QRB5165 using VOXL 2 and is built with the same sensor configurations as the Qualcomm Flight RB5.
VOXL 2 has the same computing power as the Thundercomm RB5 SOM, but a much broader support for different image sensors.
@Vinny Thanks for this info this is super helpful. I 100% agree about the last thing you said and if I can use the ModalAI power adapter then I definitely will. I got the 7.4V spec by assuming nominal 2S battery voltage to nominal 6S, which was probably a bad assumption. Even so, a 2S battery from dead to full charge is typically 6.4V to 8.4V so I figured 5V input was probably not sufficient for the power module as it was not in the range of 2S to 6S. Seems like this may not be the case though which is excellent