@RSAUser1 yeah i'd probably pass to @tom . The modem is seems connected, otherwise you wouldnt see wwan0 come up. Once I had access to AT commands I ditched QMI which I think is more or less a wrapper for those commands anyway.

@bendraper Mini can get power via USB so it's not out of the question

@Alex-Kushleyev Thank you for the detailed breakdown! I am fairly certain OP is from another team on the same project and I believe we are describing the same event. He has custody of the drone/logs so I will let him follow up with you

@tom thank you for reverting , I sorted out the issue, the file name in the voxl-qvio-server was opencv_tracking_front_intrinsics.yml instead of opencv_tracking_intrinsics.yml
and in the voxl-vision-hub the name was tracking_front which i renamed in tracking. After the above mentioned changed the voxl-qvio-server is working fine.
thank you for the support.

@JP-Drone said in Support Photo/Video Capture via RC Switch:

MAV_CMD_IMAGE_START_CAPTURE

How are you handling the mavlink camera protocol exchange within voxl-px4? I know that there is the ability to forward commands to the GCS if using mission commands (but not manually flipping an RC switch).

Alternatively when using a joystick you can map a button to image capture: https://docs.px4.io/v1.15/en/camera/mavlink_v2_camera.html#manual-controllers

Currently the mavcam manager fully implements the camera protocol to send the ack for the incoming mavlink commands. It also handles the capture and video stream status (satisfies the mavlink camera protocol).

My only issue with implementing this is that the upstream voxl-px4 will not be camera protocol compliant and thus we are bypassing the entire protocol just to get camera image capture from the autopilot instead of the GCS (which also implements the same camera protocol). If you have a way to implement the protocol (even a stripped down version of it) please send a link so I can look at the code.

@Gus-Meyer It looks to be some kind of configuration issue rather than a hardware issue. If I turn on the board while pressing the S2 switch, the USB connection is recognized. But I'm assuming this puts it in some particular mode where the device isn't used normally, because I do not receive an IP on the ethernet device under this circumstance.

@jameskuesel , can you please do a quick test:

move / rename the following file:

/usr/lib/camera/com.qti.tuned.cmk_imx577.bin

then restart camera server and take a look at the image again.

I believe the tuning file is smoothing out the image too much. the imx412 sensormodule file (also in /usr/lib/camera) is linked to com.qti.tuned.cmk_imx577.bin tuning file. By removing the file, the camera pipeline will load the default tuning file, which is what I believe your imx214 is using (com.qti.tuned.default.bin).

another thing to try is to use a different tuning file, which we have been testing, which removes a lot of the smoothing for IMX412:

cd /usr/lib/camera mv com.qti.tuned.cmk_imx577.bin com.qti.tuned.cmk_imx577.bin.bak ln -s com.qti.tuned.imx412_fpv.bin com.qti.tuned.cmk_imx577.bin #then restart voxl-camera-server

Essentially this will replace the tuning file that is currently being used with a custom one we are experimenting with.

Please let me know if these options look better.

In order to see which camera is using which tuning file you can enable a special debug mode:

add to /vendor/etc/camera/camxoverridesettings.txt:

logInfoMask=0x20000

if you see systemLogEnable=0, set it to 1:

systemLogEnable=1

run in one terminal:

logcat | grep -i tuning

Then restart voxl-camera-server and you should see in the first terminal something like the following.. chromatix file is analogous to tuning file.

voxl2-mini:/$ logcat | grep -i tuning 01-29 02:22:27.003 3844 3844 I CamX : [ INFO][HWL ] camxhwenvironment.cpp:1762 CreateTuningDataManager() Enter : sensor index: 0, sensor name: imx412_fpv, chromatix name: imx412_fpv 01-29 02:22:27.003 3844 3844 I CamX : [ INFO][HWL ] camxhwenvironment.cpp:1798 CreateTuningDataManager() Searching regular tuning file 01-29 02:22:27.014 3844 3844 I CamX : [ INFO][HWL ] camxhwenvironment.cpp:1839 CreateTuningDataManager() Loaded tuning file: /usr/lib/camera/com.qti.tuned.imx412_fpv.bin for sensor index: 0 01-29 02:22:27.118 3844 3844 I CamX : [ INFO][HWL ] camxhwenvironment.cpp:1762 CreateTuningDataManager() Enter : sensor index: 1, sensor name: ar0144, chromatix name: onsemi_ar0144 01-29 02:22:27.118 3844 3844 I CamX : [ INFO][HWL ] camxhwenvironment.cpp:1798 CreateTuningDataManager() Searching regular tuning file 01-29 02:22:27.118 3844 3844 I CamX : [ INFO][HWL ] camxhwenvironment.cpp:1811 CreateTuningDataManager() No tuning data file for sensor: ar0144, assigning default 01-29 02:22:27.127 3844 3844 I CamX : [ INFO][HWL ] camxhwenvironment.cpp:1839 CreateTuningDataManager() Loaded tuning file: /usr/lib/camera/com.qti.tuned.default.bin for sensor index: 1 01-29 02:22:27.158 3844 3844 I CamX : [ INFO][HWL ] camxhwenvironment.cpp:1762 CreateTuningDataManager() Enter : sensor index: 2, sensor name: imx214, chromatix name: imx214 01-29 02:22:27.158 3844 3844 I CamX : [ INFO][HWL ] camxhwenvironment.cpp:1798 CreateTuningDataManager() Searching regular tuning file 01-29 02:22:27.158 3844 3844 I CamX : [ INFO][HWL ] camxhwenvironment.cpp:1811 CreateTuningDataManager() No tuning data file for sensor: imx214, assigning default 01-29 02:22:27.163 3844 3844 I CamX : [ INFO][HWL ] camxhwenvironment.cpp:1839 CreateTuningDataManager() Loaded tuning file: /usr/lib/camera/com.qti.tuned.default.bin for sensor index: 2

I currently have hooked up 3 cameras, my results probably wont match yours since i don't have exactly the same setup and drivers, but you can see what to expect.

After testing, you can disable the log mask and system logging to reduce cpu usage.

Alex

@Amin-Bassiri You can either fully re-flash the drone or just run voxl-configure-mpa in order to bring the drone back to it's default state based on the SKU

@KnightHawk06 , please upgrade your VOXL2 SDK, as you have very old release, you can get the latest SDK 1.4.0 and then configure your cameras.

https://docs.modalai.com/sdk-1.4-release-notes/

After installing latest SDK and configuring cameras, confirm via ADB shell that camera server is getting camera data:

#this test app will subscribe to all camera streams and report stream resolution, fps, etc #please note that this test can put unnecessary stress on the system because it will stream ALL the possible camera streams, so normally you would not run this test all the time voxl-inspect-cam -a

after that, if you want to view the camera stream using voxl-portal but you do not have internet connection, you can do that using adb port forwarding trick : https://docs.modalai.com/voxl-portal-via-adb/

Let us know if you have any other questions.

Alex

Hi @jcai ,

I am not sure about this one.. If a higher kernel version is required and the existing driver does not actually work, then maybe it is not a big surprise! 🙂

the kernel module is in the build, as specified in the config file here : https://gitlab.com/voxl-public/system-image-build/qrb5165-kernel/-/blob/qrb5165-ubun1.0-14.1a/arch/arm64/configs/vendor/kona-perf_defconfig#L328

Some info about the driver : https://gitlab.com/voxl-public/system-image-build/qrb5165-kernel/-/blob/qrb5165-ubun1.0-14.1a/arch/arm64/boot/dts/vendor/bindings/net/microchip,lan78xx.txt

You could try to pull source code from updated driver for this device from a newer kernel, drop it into the voxl2 kernel build and build the kernel with new driver. I think some users on this forum were able to do something similar with another device (not ethernet adapter).

Maybe try another ethernet adapter? 🙂

For example,

voxl2-mini:/$ lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 10000M |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=ax88179_178a, 5000M voxl2-mini:/$ ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full ... Speed: 1000Mb/s Duplex: Full ... voxl2-mini:/$ iperf -c <my desktop machine ip> ------------------------------------------------------------ Client connecting to <my desktop machine ip>, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local <my voxl2 local ip> port 52708 connected with <my desktop machine ip> port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 339 MBytes 284 Mbits/sec

Did not quite get 1 gig (about 300Mbit/s), maybe there is a bottleneck somewhere, but maybe that will work for you..

Alex

yes, that's the correct rotation matrix for a tag on the ground.

For a tag on the wall with a center 1m off the ground you can use:
"T_tag_wrt_fixed": [0, 0, -1],
"R_tag_to_fixed": [[0, 0, 1], [1, 0, 0], [0, 1, 0]]

The second video of this docs page walks you through the voxl-vision-hub command line args to help you debug relocalization.

@JP-Drone ,

Please try to upgrade to latest voxl-portal version from here : http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64//

I just tested on iphone displaying individual and multi view, it works. What camera feed are you selecting (name)?

The non "encoded" feeds are compressed to mjpeg format which should play on majority of browsers.

I will check regarding the video recording feature in voxl-portal.

Alex

@bendraper We use Google Fi data SIMs for all of our testing