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

Hi @modaltb Travis, it took me a bit to have time to get back to this, but I've confirmed the problem. There was a short between input and ground in the small 4-pin GH connector I was using to connect to the VOXL2 IO board. Given I just found that laying around, I should have caught this earlier. Thanks for your help! I can confirm that the PX4IO app does see the R9SX input now. I'll also refer to your other post soon about trying to setup the Graupner GR-16 as I'll be moving to that this summer.

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.

@m1baldwin With that platform release PX4 crashing causes ADB to crash as well, so that's one possibility. (This is fixed in future releases) If it was a camera issue, that would be low level device tree code causing the crash

Thanks for the response. It worked !!

@afdrus instead of rebooting, you can restart the server with: systemctl restart voxl-camera-server

I resolved this by doing 1 of 2 things Powercycle Add nameserver 8.8.8.8 to /etc/resolv.conf These are only temporary fixes, but get the job done so I can keep developing

@Chad-Sweet We would be doing RMA for this VOXL2 chip since it is not in recoverable stage from our tests.

@Eric-Katzfey Thanks Eric, for future readers, I've created a new post at Voxl 2 Spektrum RC Issue.

Hi @Aks , Out of the box no, but if you are recompiling SW yourself than it's likely doable, but we have not tested this. voxl-px4 utilizes the DSP for it's IO on VOXL2, do the UARTs aren't exposed to Ubuntu like a normal UART (/dev/ttyHX). Instead it's a little deep in voxl-px4 at this time. The current production release is a 1.12 based branch, called voxl-dev-1.12. For example, the QUP2 port is defined here for the ESC: https://github.com/modalai/px4-firmware/blob/voxl-dev-1.12/src/drivers/uart_esc/modalai_esc/modalai_esc.cpp#L42 And QUP7 is defined to be used by px4io here: https://github.com/modalai/px4-firmware/blob/voxl-dev-1.12/platforms/qurt/src/px4/generic/generic/px4io_serial/px4io_serial.cpp#L67 For reference, I used my own graphic to remember the QUP indicies, here: https://docs.modalai.com/voxl-px4-developer-guide/ specifically: https://docs.modalai.com/images/voxl2/m0054-px4-block-diagram-0.4.png Although we haven't tried this, you may be able to recompile with updates here to the QUP index and get things going that way.

Hi @modaltb, We were making a mistake of connecting the mavros with the UART which is being used by mavlink server, hence creating the traffic in communication. Now we are connecting mavros with VVPX4 and it's working fine. Thanks.

A small observation from my side. While we are flying the quad indoors with compass disabled and using a external optical sensors (in both cases) the qvio recovers itself even after force restarting it using terminal, but the same does not recovers itself outside. For both the cases the exposure and gain of tracking cam was in auto. Can you tell us what might be the issue

Thanks! this is helpful confirmation

Hi @Aks I will need to investigate, our beta releases are subject to bugs as they've not gone through our standard test flow and are generally provided to end users to test out a particular feature. So I do not trust the beta image for flight at this point, we've not posted one of these beta images publicly so if you have it it's likely to test a one off feature and not recommended for flight...