Hey @dvPr1m3 , How were you able to do it on VOXL 2?

After connecting the VOXL2 Mini to an external flight controller as described here via J10 on VOXL2 Mini, MAVlink data was viewable from a VOXL Flight Core v2. We are still having some troubles with viewing the streams, however now the stream/camera names are appearing in QGC with the video feed selector now that the above MAVlink connection has been established. It seems like in order to route MAVlink data out of J3 on VOXL2 Mini via USB, we will need to look into MAVrouter or a similar solution. For now we will continue integration via J10. Our goal with routing MAVlink data via USB on VOXL2 is to reduce the telem connections required on a flight controller for our product. We would like the ability to run multiple RTSP streams and MAVlink communication via a single USB connection (from J3 on VOXL2 Mini) to an external flight controller. Is UART communication via J10 the preferred or only method of communicating with VOXL2 Mini over MAVlink? Is there a way to do MAVlink routing with the VOXL SDK as I mentioned, or will this need to be custom implementation? If the VOXL2 Mini is receiving MAVlink data via a UART connection from another device, will the VOXL2 Mini forward and receive MAVlink data to/from the MAVlink device through to a Flight Core via the external flight controller connection J10 on VOXL2 Mini? Thank you for very much for your time and feedback on this topic.

@tahawaru It's just a change in the naming. Used to be platform, now is SDK. Go with the most recent SDK.

@jacob-yaacubov , I am not sure why this is happening. However, you maybe able to debug this yourself using gdb and starting the ros node manually: gdb /opt/ros/melodic/lib/voxl_mpa_to_ros/voxl_mpa_to_ros_node r __name:=voxl_mpa_to_ros_node __log:=/opt/ros/foxy/log/my_new_ros_log/voxl_mpa_to_ros_node-1.log (wait for crash) bt (this will print stack backtrace, at least will tell you in which function the crash occurred) Please try..

@Nicholas-Clark you can find the voxl-cross Dockerfile and source here. We're happy to incorporate merge requests if you feel you have a solution that can be generalized across our customers.

@AndriiHlyvko Thanks! We have merged in those changes.

maybe voxl-replay....

@Eric-Katzfey I am not able to run pythorch/Onnx model on GPU or NPU, do we have any examples for that? I could only find the tflite examples. I was able to run the Light Glue model on docker with CPU.

@Ritwik-Majumdar The delay of VOXL2 control has not been tested, but it should be relatively small (1ms or less) You can control the GPIO directly from command line, see https://docs.modalai.com/voxl2-linux-user-guide/#gpios https://docs.modalai.com/voxl-gpio-io/#manipulating-gpio-using-linux-commands Please take note of the GPIO pin numbering : the GPIO have an offest of 1100 (e.g. GPIO 84 = 1184) Setting CPU to perf mode (voxl-set-cpu-mode perf) will speed things up. You can time the execution time (i just did in perf mode). Sometimes 0.000s, sometimes 0.001s, so somewhere around 1ms. You can do more precise timing if needed. voxl2:/$ time echo 1 > /sys/class/gpio/gpio<GPIO_NUM>/value real 0m0.001s user 0m0.000s sys 0m0.000s

@Rowan-Dempster No, it isn't

@xianglic That looks very similar to the one I use. Is it not working for you?

@tom cool. I created an MR with wrong source branch by mistake so just delete that one. But this one is the right one: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/merge_requests/42

@achanana said in MAVSDK example program on VOXL 2 not running: voxl-px4-imu-server is for the Qualcomm Flight RB5 architecture and is not relevant to Starling It is likely your voxl-mavlink-server is not configured properly. MAVSDK communicates with the port opened up in voxl-mavlink-server

Thanks @Eric-Katzfey and @tom, appreciate your assistance! I will try the Docker approach, I will reach out if I have any issues interacting with MPA from the Docker container.

@Projects-a You can connect the i2c to the J5 connector on M0141 and spi to J10 on VOXL 2 board if you want to stay with M0141

@thomas I assume we don't want to be dealing with 4k raw arrays on the CPU for performance reasons. So yeah as early as possible in the image proc pipeline, and how early we can push it is what I'm asking for advice on. We'll also reach out to @Alex-Kushleyev thanks!!