@Prabhav-Gupta , you are welcome!

@Zachary-Lowell-0 well it work now! I found these lines on another thread of the forum: sudo apt-get install voxl-ros2-foxy sudo apt-get install voxl-mpa-to-ros2 voxl-configure-mpa-to-ros2 source /opt/ros/foxy/mpa_to_ros2/install/setup.bash export ROS_HOME=/opt/foxy ros2 run voxl_mpa_to_ros2 voxl_mpa_to_ros2_node And everything worked first time ! So please put these line directly on the documentation cause I lost so much time with this install !

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

@Judoor-0 , I am sorry, but i cannot help you with the mavsdk issue due to lack of knowledge of the subject. Please follow up in the appropriate thread and someone else should help you out! Alex

@ejohnson Yes, that is a bug. Don't have a suggestion off the top of my head.

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

@Jeffrey-Mao , no worries, thanks for the update!

@Alex-Kushleyev Thanks for the information. I think I understand what is going on my end then.

@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

@Zachary-Lowell-0 @Moderator A really important question here is what if there are two drones publishing the same name FMU topics and you haven't set the domain id different for those drones for data sharing through your custom interfaces. PX4 ROS2 docs provide a way to change the namespace of the FMU topics to be published but MODAL AI docs mention no such thing? Is there a way to do that? As most of the starling systems are being used as a swarm platform this thing is really critical

@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!!

@Moderator Thanks for the response. Follow up question, are the voxl-side timesync requests only used for updating gps timestamps? After reading the code you linked and running mavlink-server in timesync debug mode I think that the only thing not working is the voxl timesync requests. It looks like when I start sending hil_gps or odometry mavlink messages to the autopilot pipe, one of the autopilot's responses to the voxl timesync requests is dropped or comes in after a new value for last_voxl_time_sent is generated. Then the timesync handler can't recover because it's getting responses that are 1 step behind moving forward (see below). Since it looks like it continues to get reasonable values for now-ts1 for the autopilot requests, I don't think this is an issue depending on what voxl-side timesync is being used for. Not sure why I'm getting the RTT too high warning in my PX4 log though output from mavlink server timesync debug mode at the point when I started sending odom/gps mavlink messages to the autopilot: sending our own ts request at 408744677609 ap ms ahead of voxl: -0.2ms timesync: now-ts1 = 0.6ms sending our own ts request at 408845331615 ap ms ahead of voxl: -0.3ms timesync: now-ts1 = 0.9ms sending our own ts request at 408945169337 timesync: now-ts1 = 0.2ms sending our own ts request at 409044439310 timesync: now-ts1 = 0.3ms sending our own ts request at **409145346227** timesync: now-ts1 = 0.5ms sending our own ts request at **409244599326** unknown timesync request ts1 = **409145346227** tc1 = 409263819000 last_voxl_time_sent = 409244599326 timesync: now-ts1 = 0.3ms sending our own ts request at 409345147918 unknown timesync request ts1 = **409244599326** tc1 = 409406867000 last_voxl_time_sent = 409345147918 timesync: now-ts1 = 0.2ms sending our own ts request at 409445248290 unknown timesync request ts1 = 409345147918 tc1 = 409506047000 last_voxl_time_sent = 409445248290 timesync: now-ts1 = 0.2ms sending our own ts request at 409545084726 unknown timesync request ts1 = 409445248290 tc1 = 409608198000 last_voxl_time_sent = 409545084726 timesync: now-ts1 = 0.4ms sending our own ts request at 409645091472 unknown timesync request ts1 = 409545084726 tc1 = 409717154000 last_voxl_time_sent = 409645091472