@Moderator Oh, thank you so much for sharing it. I'll check it!

@Wei-Cui you could write your own hi-res overlay to render whatever information you'd like. You can see the qvio-overlay source code here. You would need to create your own service that received the high-res data, drew the overlay, and then published over MPA as a new pipe. voxl-portal will automatically grab all of the camera pipes and make available as potential streams

@JSchinowsky These should help you out:

voxl add-on: https://docs.modalai.com/microhard-add-on-datasheet/#board-connections-and-io
standalone: https://docs.modalai.com/microhard-usb-carrier/#board-connections-and-io

@Aaron-Porter I am facing the same issue, is it solved?

@tiralonghipol I have never used that sensor but from the code it looks like adc_report is indeed the data it is publishing.

@Felipe What mavlink message(s) would this sensor be sending over the UART?

@tom I was able to pug the hardware to the expansion board that goes to the j13 port of the voxl flight,

lsusb the one im using is the Bus 001 Device 002: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter

Screenshot from 2023-10-25 18-45-49.png

the success connection of the hardware
conection_succes.jpeg

the setup

setup.jpeg

Hi @Zachary-Lowell-0, sorry for the late reply.
I've run the test that you asked with the new code that you wrote (v0.3.7). The results were pretty random, we go from a lower bound of 3 detections sent through voxl-mpa-to-ros over 10 detections present in tflite, to an upper bound of 8 over 11.
This happens also for a small number of detections i.e. 2/4 as lower bound to 3/3 as an upper bound.

Are your tests aligned with mine? I'm still using a custom yolo v5 for 2 class detections.

@Zachary-Lowell-0 @Eric-Katzfey Yup, all's good now after stopping voxl-qvio-server. Thanks for the help!

@tom Thanks

@I_Dwyer @Chad-Sweet Hello all, has this issue been solved in and particular version, we too are facing the same issue, on HS1 the voxl-mavlink server is initiating but we are not able to see any data from this port. We are right now on the 1.5.3 build. Pls provided more info on the same.

@Eric-Katzfey said in Starling infinite loop switching between Position and Manual mode:

And if you start voxl-camera-server and then put it into position mode is that okay?
Not immediately. The longer the system was in the endlessly switching state the longer it takes for it to recover even after voxl-camera-server is started. Can be in the order of minutes.

My guess is that you stopped voxl-camera-server but not some of the other services that depend on it like voxl-qvio-server, voxl-vision-hub, etc. and so they are sending erroneous data to px4 which confuses it.
During this weird behavior I have attempted to turn off all other services that might be doing this, which includes the 2 that you have mentioned. The only exception is voxl-mavlink-server which obviously I can't turn it off but after restarting it, it's still weird behavior is still present.

You are, obviously, trying some non-standard stuff here.
Yes I do understand that. I'm just wondering why it appears only when the WiFi interface is used for communication and not when cellular 5G is used...

Also, with respect to the RC, make sure you set RC=EXTERNAL in /etc/modalai/voxl-px4.conf so that the RC drivers are not started needlessly.
Ok will do so thanks

@Moderator thank you for your help. When I run cmake it throws an error saying that it cannot locate OpenCV, I am using

find_package(OpenCV REQUIRED)
include_directories( ${OpenCV_INCLUDE_DIRS} )

This is from the OpenCV documentation but it does not work for me. What could be the solution?

@martongonczy You'll need to use an MPA based client in order to read from the pipe, like in voxl-inspect-cam : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/master/tools/voxl-inspect-cam.c?ref_type=heads

what you're seeing is voxl-tflite-server reading from the hires pipe