@Matt-Turi Thanks !!

Kind of. I'd just like to know where the origin is of the IMU data reported by the voxl-imu-server MPA service (as quoted above). If it's at the center of one of the specific IMUs then that link is comprehensive to figure out the dimensions. But I haven't been able to find where that origin is. My guess is at the center of the board, but I'd like to confirm.

Hi @Aks , please refer to other thread where I have some info, thanks!

Thanks, for your quick response @Chad-Sweet .

We have already flight tested part of the setup above (except HereFlow), and it seems to work great.

Please find connection details in the attached picture below:VOXL2_SysArch.png

On this note. Does anyone know what happened to the hellocl repo? The link on the Build Applications for VOXL, VOXL 2 and RB5 Flight page in the docs does not lead anywhere anymore.

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...

Thanks! this is helpful confirmation

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

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.

@tom That qdl reset did the trick, thanks!

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.

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

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

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

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

Thanks for the response.
It worked !!

@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

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.