VOXL 2 runs an Ubuntu 18 OS, and we're not doing anything special to control networking functionality. Have you looked at the tutorial like this to see if you can configure that way?

Hi @McMason , What's your hardware setup like, image sensor (imx214/412/678?) and flex extensions (none, short M0074, long M0036) and port being used? J7/J8? System image version 1.4.1 or 1.5.5? https://docs.modalai.com/voxl2-system-image/#changelog And what about your setup in /etc/modalai/voxl-camera-server.conf ? Lots of times intermittencies like this are flex related (e.g. length, or kinks or connection), in general we have this setup the IMX214 setup in our Sentinel drone which is running continuously so it's not expected behaviour to crash!

Hi @modaltb, we are having that issue on a certain VOXL2 board. We had an extra Voxl2 we put in and the issue isnt there as expected. Once i get a free moment ill dig back into the problem board. as of now its ok.

@Eric-Katzfey I've been stuck on travel for the past month but happy to report that your solution worked! input_rc is publishing and I was able to calibrate in QGC.

@Tamas-Pal-0 That sounds like a good question for the PX4 community. We don't have any experience flying with a distance sensor but I'm sure others in the PX4 community do this all the time.

@Aks You should be able to run two. But, again, we have never tested.

Because on my voxl2 it seems that neither this configuration nor the 2TOF2 configuration is possible... [image: 1680703429182-screenshot-from-2023-04-05-16-02-47.png]

https://docs.modalai.com/voxl2-io/

@modaltb thank you for your answer. For so far I can see my program is the same. I'll take some more indepth look when I'm at work again. Is there some .so file I've got to include in my cmakelist? I've already tried every possible combination that's out there. Hope we can fix this soon.

Outstanding!

That's cool! We have never tried that tool. Do you have instructions or a pointer as to how it works?

I tried adding the .so file to the hellocl example, and got the following error: /usr/lib/gcc-cross/aarch64-linux-gnu/7/../../../../aarch64-linux-gnu/bin/ld: warning: libcutils.so.0, needed by /usr/lib/../lib/libOpenCL.so, not found (try using -rpath or -rpath-link) /usr/lib/../lib/libOpenCL.so: undefined reference to `property_get' and when adding it to our OpenCV application, OpenCV still cannot find any OpenCL devices. I suspect OpenCV needs to be recompiled with the .so file in the docker image. This issue is not immediately pressing, so if you intend to update the voxl-cross image I can wait for that instead of trying to create a fix.

Sensor ID 0x003D is a ToF right? Seems like you have a Tof and Tracking, but you are trying to use a configuration for tracking and hires (4). https://docs.modalai.com/voxl2-camera-configs/#c4---tracking-and-hires-only

Hi, we have it on our roadmap but not defined release, we're hoping to do this over summer time. There's a pending Ubuntu 20 release from Qualcomm that we can use but need to port it over to our platform etc.

Hi @Aks, That makes architectural sense to try out! Let us know how it works!

@Noe-Medrano scp is a basic linux utility so you should be able to find solid documentation on it's usage, but you can do the following to download a single file: scp root@VOXL2_IP:/data/px4/log/FILE_NAME HOST_PC_DIRECTORY

Hello @MartinP , I believe here is what is happening in your case: Your sensor (Lidar) is sending data continuously without any breaks (360 degree lidar?). Maybe the Lidar processes each measurement and sends it out right away, so perhaps there are small breaks between the data measurements The hardware UART buffer size in VOXL2 is set to 2048 (based on the data chunk size you get) You are using the High Speed uart port (HS in the ttyHS1), which uses DMA to transfer data to cpu (one cpu interrupt per buffer) Typically, the DMA-based UART hardware decides when to send the data to CPU when one of several conditions is met: there is a long enough break in the data stream that can be considered end of "packet" or the current data buffer is full (2048 in this case) Since it looks like the data from Lidar is coming without long breaks, I see several possible solutions: If possible, configure the Lidar to have a break between each scan (but you would need to know the minimum break size for UART hardware to trigger a rx interrupt to CPU) reduce the rx buffer size for UART (probably somewhere in the Device Tree) However, it would be helpful to understand what the data transmission from Lidar looks like. Also, please note that increasing the baud rate of the communication will probably not help. Significantly increasing the baud rate may result in potentially rx interrupt triggering on each measurement, which would not be very good for the CPU.