@maoyuanchao is the vehicle 'flat' on a table? even the accel values in Y and Z aren't what I would expect.
I've seen issues with gyro (say after a very hard crash) in which the MEMs internals get messed up (think of them as a hair comb looking structure that measure capacitance at the smallest of levels) and these comb structures are cracked, but the values aren't nice "0.00" rather noisy....
I found this page that doesn't have the exact model above, but other similar models are stating UVC (for video) and CAN (for control) as interfaces.
https://xacti-co.com/solution/drone/ardupilot/
The UVC portion could work (https://docs.modalai.com/voxl-uvc-server/) although we've never tried this and there's a chance the kernel of VOXL2 could require some small tweak to work if the USB ID isn't recognized for some reason.
For the control portion, we don't support CAN on VOXL2, so that interface wouldn't work unfortunately.
You'd end up with stabilized video, but likely no way to control zoom/pan/tilt etc.
Hi @이광철 ,
We defaulted this interface to SPI starting in SDK 1.1.2.
https://docs.modalai.com/voxl2-mini-linux-user-guide/#system-image-17
https://docs.modalai.com/voxl2-voxl2-mini-system-image/#system-image-changelog
It can be converted back to SPI with a kernel change and rebuild if you are able to try that.
https://docs.modalai.com/voxl2-kernel-build-guide/
Enable:
https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/blob/qrb5165-ubun1.0-14.1a/recipes-kernel/linux-msm/files/dts/m0104/m0104-modalai-qupv3.dtsi?ref_type=heads#L93
Disable:
https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/blob/qrb5165-ubun1.0-14.1a/recipes-kernel/linux-msm/files/dts/m0104/m0104-modalai-qupv3.dtsi?ref_type=heads#L98
TLDR; we should likely try to collaborate on getting a bitbake recipe going that modifies what we need, and try to get this going in our next "Ubun2.0" update as I'm trying to gain momentum there.
I'm up to get on the phone with you if it makes sense! Maybe first it's worth us exploring how to best enable development for people on the kernel moving forward, and how to clean things up (e.g. branch names!)
Jumping around the questions a little right now, with likely what we need to do is have some working meetings together to figure out stuff.... Maybe a VOXL2 Kernel Steering Committee or something....
For the current active development for SDK 1.X releases, where system image is a 1.X version, and kernel is 4.19 based - I will continue to use qrb5165-ubun1.0-14.1a branches, eg.
For next major SDK update (e.g. 2.X), we are targeting "Chipcode Ubun2.0":
E.g.
sh-5.0$ uname -a
Linux qrb5165-rb5 5.4.233 #1 SMP PREEMPT Tue Dec 5 17:56:30 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux
sh-5.0$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS
Release: 20.04
Codename: focal
Here's info about the kernel we plan on moving to at this point:
kernel: https://git.codelinaro.org/clo/la/kernel/msm-5.4/-/tree/kernel.lnx.5.4.r47-rel
techpack/camera: https://git.codelinaro.org/clo/la/platform/vendor/opensource/camera-kernel/-/tree/camera-kernel-iot.lnx.2.0.r2-rel
If you want.... I can share rootfs and kernel to play with... zero warranties at this point 
@hmlow ,
Yes I think we flipped a camera config here inadvertently...
Can you try this?
vi /usr/bin/qrb5165-configure-cameras
Change this:
6) # D0005 Starling V2 Hires + TOF + Tracking
CAM_LIST+=("tof:pmd-tof:0")
CAM_LIST+=("hires:${HIRES_SENSOR}:1")
CAM_LIST+=("tracking:ov7251:2")
BIN_LIST+=("/usr/share/modalai/chi-cdk/ov7251/com.qti.sensormodule.ov7251_3.bin")
BIN_LIST+=("/usr/share/modalai/chi-cdk/irs1645/com.qti.sensormodule.irs1645_0.bin")
BIN_LIST+=("/usr/share/modalai/chi-cdk/${HIRES_SENSOR}/com.qti.sensormodule.${HIRES_SENSOR}_2.bin")
;;
to this
6) # D0005 Starling V2 Hires + TOF + Tracking
CAM_LIST+=("tof:pmd-tof:0")
CAM_LIST+=("hires:${HIRES_SENSOR}:2")
CAM_LIST+=("tracking:ov7251:1")
BIN_LIST+=("/usr/share/modalai/chi-cdk/ov7251/com.qti.sensormodule.ov7251_2.bin")
BIN_LIST+=("/usr/share/modalai/chi-cdk/irs1645/com.qti.sensormodule.irs1645_0.bin")
BIN_LIST+=("/usr/share/modalai/chi-cdk/${HIRES_SENSOR}/com.qti.sensormodule.${HIRES_SENSOR}_3.bin")
;;
;;
Just tried this on my setup:
Hey @Zachary-Lowell-0 ,
So you have a custom driver for realsense going right? We don't have anything going for realsense so we aren't trying to probe anything (assuming you mean access the interface (not sure if it's UART/USB/I2C etc) but portal definitely isn't going to be interacting with devices like that.
Total hack, but this just worked. We still need a clean way of uninstalling opencv2.4
$ opkg list | grep opencv
$ opkg remove lib32-opencv --force-removal-of-dependent-packages
$ opkg list | grep opencv
$ opkg remove lib32-opencv-dbg --force-removal-of-dependent-packages
$ opkg remove lib32-opencv-calib3d2.4 --force-removal-of-dependent-packages
$ opkg list | grep opencv
$ opkg remove lib32-libopencv-calib3d2.4 --force-removal-of-dependent-packages
$ opkg list | grep opencv
$ opkg remove lib32-libopencv-core2.4 --force-removal-of-dependent-packages
$ opkg install opencv_3.4.6_8x96.ipk
$ /usr/bin/opencv_version
3.4.6
Installing OpenCV-3.4.6.ipk fails on voxl_emulator opkg install OpenCV-3.4.6.ipk. Even tried compiling and installing the generated ipk. Likely issue with installed opencv2.4 version from ROS.
Deploy on VOXL target works fine.
We've posted a git-perltools package that should provide a workaround for this issue if you install on the either the emulator image or the target. Note at this time, when using on the emulator, you'll need to run it again after exiting...
Download the git-pertools package from here: https://docs.modalai.com/docs/resources/downloads/#additional-packages
Copy to the emulator (place in directory where you run the emulator from) or target (using adb push)
Install using `opkg install lib32-git-perltools_2.5.0-r0_armv7a-vfp-neon.ipk' (note: some opkg warnings will display but can be ignored)
You should be able to use the submodule command after this. Please let us know if you have any problems.
git submodule update --recursive Throws following error
git: 'submodule' is not a git command. See 'git --help'.
Missing git-perltools in the voxl-build?
VOXL Emulator Docker Image (1.0.0)
voxl-emulator latest 0e15518b8f95 12 months ago 1.26GB
Answers to some of your questions:
The VOXL is meant to be a flexible development platform that allows developers to choose where best to run the components of their application. There is documentation describing various CPU and DSP development paradigms. The GPU is typically accessed via OpenCL and OpenGL. In general, the CPU is used for most things, the "sensors DSP" (aka SLPI, SDSP) runs the flight controller (SNAV, PX4 in the near future), and the GPU offloads certain OpenCV or other applications via OpenCL / OpenGL. The "applications DSP" (aka ADSP) is not really used for anything right now but is accessible. There is also a hardware video accelerator known as "Venus" that can offload certain tasks via OpenMAX.
There is flexibility with how sensors are attached to the system. Cameras primarily come in via the MIPI connectors. Each camera, however, requires custom support. There are some supported "out of the box" (eg OV7251, IMX214, etc.), while new ones would have to be developed. Cameras can also come in via USB using UVC. There are IMUs on the VOXL that can be accessed directly via the SDSP. There is GPS capability directly on VOXL (See the GPS antenna connector) that can be accessed via SNAV or else an external GPS unit can be attached via the J7 connector. There are other lots of other options as well depending on the application.
Load on CPU and GPU can be monitored using our voxl-perfmon python script (https://gitlab.com/voxl-public/voxl-utils/-/blob/master/bin/voxl-perfmon). We will add DSP to this as well.
Hello,
I am trying to get a better grip of what runs where with Voxl, and I am having a hard time determining this from the modalai and Qualcomm documentation. We are using snav on the 820 Flight Pro platform.
My questions are:
What Voxl components run on the
Qualcomm Navigator is comprised of multiple libraries, executables, and configuration files. The core flight controller runs on the aDSP, and other components run on the applications processor and GPU. Qualcomm Navigator provides a low-level C API for applications to interact with the flight controller.
Where do the sensors come in to the system
How do I determine the load on
Regarding the DSP, I have read the 820 DSP is made up of four smaller application specific DSPs, and I see there is support for developing for the aDSP an the sDSP. Can you elaborate on what each of these should be used for, and what is already running on each of these? I have found the two support pages for these here
https://docs.modalai.com/build-for-sdsp/
https://docs.modalai.com/build-for-adsp/
Thanks,
An example of how to do this was created can be found here