@K-Stute here is the directory in voxl-dev px4-firmware: https://github.com/modalai/px4-firmware/blob/voxl-dev/src/modules/microdds_client/dds_topics.yaml

@jacob-yaacubov , FYI, this fix will be in 1.2.0 release which is in testing now

@Zachary-Lowell-0 Thanks Zach, this does answer. I have been used to ROS1/MAVROS where sending position targets was completely ignored unless in offboard mode so my node would typically blast setpoint_raw messages whether in offboard or not (in part to keep the option of switching to 'offboard' mode "alive"). I will proceed from now on in ROS2/MicroXRCE assuming I should constantly send offboard control mode messages, but send traj setpoints only when offboard mode is confirmed. I appreciate the clarification on why this is. -Joe

For a final wrap-up, we installed ROS2 Humble from Source on Voxl2 this fixed the communication issues. We also noticed in Foxy if we we had the following set up on the same device Publisher A -> (TOPIC A) Subscriber A (Which Publishes Topic B ) Topic A publishes 500Hz Topic B publishes at 400Hz ish In Humble, Topic A publishes 500Hz Topic B publishes at 500Hz

I just tried this real quick on VOXL1 and indeed there is an issue related to pty on PC: docker pull arm64v8/ros:rolling-ros-core docker image save arm64v8/ros:rolling-ros-core | gzip > rolling-ros-core-arm64v8.tar.gz adb push rolling-ros-core-arm64v8.tar.gz /data/ on VOXL1: adb shell cd /data docker load < rolling-ros-core-arm64v8.tar.gz cd /home/root mkdir ros2 cd ros2 docker run -it --rm --privileged -v `pwd`:/home/user -w /home/user arm64v8/ros:rolling-ros-core #now inside docker container apt-get update apt install python3-colcon-common-extensions then follow example to set up a demo project : https://roboticsbackend.com/ros2-launch-file-example/ run (inside docker container) colcon build Error: stdout_descriptor, stdout = pty.openpty() File "/usr/lib/python3.10/pty.py", line 34, in openpty master_fd, slave_name = _open_terminal() File "/usr/lib/python3.10/pty.py", line 64, in _open_terminal raise OSError('out of pty devices') OSError: out of pty devices --- Failed <<< my_robot_bringup [0.21s, exited with code 1] Summary: 0 packages finished [3.72s] 1 package failed: my_robot_bringup 1 package had stderr output: my_robot_bringup out of pty device After doing a quick search, cannot figure it out. It is probably related to very old docker version on VOXL1.. Not sure if anything can be done..

Hi @dlee and @smilon so if you are installing your vision_opencv into sudo, then the conflicts will wipe out a ton of MPA and SDK programs. This is highly recommended NOT to be done. Instead either use docker, or leverage the package as a third party in a virtual environment or something along that nature. voxl-vision-hub should be on target from the SDK installation: voxl2:/$ sudo apt-get install voxl-vision-hub Reading package lists... Done Building dependency tree Reading state information... Done voxl-vision-hub is already the newest version (1.7.3). voxl-vision-hub set to manually installed. 0 upgraded, 0 newly installed, 0 to remove and 37 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. However, most likely had the deb wiped or reconfigured when installing the opencv you were trying to leverage. Provided you guys are on sdk 1.1.2, you can just go into the tarball that has since been untarred and adb push the voxl-suite/voxl-vision-hub deb to the voxl2 and then do a sudo dpkg -i voxl-vision-hubXXXDEB - that will install it back onto the system. The other option is to either reflash or do a sudo apt-get upgrade which would pull the most recent debs from the modalAI apt repository on the cloud. Let me know if this helps either of you!

@Eric-Katzfey We got around it by forcing UART mode and connecting through an FTDI converter. Thanks anyway!

Ok, in a stroke of epipahny I realised that when switched to offboard mode through ROS2, the drone attempts to do both the modalAI "figure eight" that was configured in /etc/modalai/voxl-vision-hub.conf and satisfy the TrajectorySetpoint given to it by ROS2, resulting in this very jerky motion. Switching offboard_mode parameter to "off" solved this issue!! Works flawlessly now. Any ideas how I can switch off passing the local odometry to PX4 and pass /vvhub_body_wrt_fixed instead? If I just publish to /fmu/in/visual_vehicle_odometry does it only take input from the publisher or will it publish from both sources similar to the offboard mode example? :)))

@K-Stute Running in a Docker is the most straightforward way to do this. We are planning an update to Ubuntu 20.04 in the future but the timeline on that isn't certain yet.

@Kyuhyong-You It actually turned out that the host-pc has ufw enabled. Disabling ufw solved the issue. Thanks

@Kyuhyong-You Take a look at the file /usr/bin/voxl-px4-start. That is the file that starts all of the PX4 drivers, modules, etc. Look for the microdds_client start -t udp -h 127.0.0.1 -p 8888 line and comment that out.

@Kyuhyong-You After reboot this error is magically gone. now I can see topics after $ ros2 run voxl_mpa_to_ros2 voxl_mpa_to_ros2_node then in another terminal on voxl, I see below topics $ ros2 topic list /fmu/in/obstacle_distance /fmu/in/offboard_control_mode /fmu/in/onboard_computer_status /fmu/in/sensor_optical_flow /fmu/in/telemetry_status /fmu/in/trajectory_setpoint /fmu/in/vehicle_attitude_setpoint /fmu/in/vehicle_command /fmu/in/vehicle_mocap_odometry /fmu/in/vehicle_rates_setpoint /fmu/in/vehicle_trajectory_bezier /fmu/in/vehicle_trajectory_waypoint /fmu/in/vehicle_visual_odometry /fmu/out/failsafe_flags /fmu/out/position_setpoint_triplet /fmu/out/sensor_combined /fmu/out/timesync_status /fmu/out/vehicle_attitude /fmu/out/vehicle_control_mode /fmu/out/vehicle_local_position /fmu/out/vehicle_odometry /fmu/out/vehicle_status /parameter_events /rosout

@Kyuhyong-You I found solution. This error was resolved by apt installing libtinyxml2 by sudo apt install libtinyxml2-dev

Sure thing @Kyuhyong-You . That is correct - currently the voxl2 runs the microdds client instead of the uxrce dds client on 1.14.0 stable. The microdds client starts automatically on the voxl2 when px4 is instantiated - if not, feel free to build PX4 yourself and flash it on the board via the instructions here: https://docs.modalai.com/voxl-px4-dev-build-guide/ There is also another service available on SDK 1.1 (https://docs.modalai.com/sdk-1.1-release-notes/) called microdds-agent which spins up the agent to listen to localhost port 8888 and allow for comms similar to mavsdk. https://docs.modalai.com/ros2-installation-voxl2/

@tom Thank you for the reply! Will be updating to the image today!

@atilla-bleda At least for VOXL Flight drones (I haven't used VOXL2), the voxl-mpa-to-ros bridge is based on ROS indigo, which means that you're going to have to implement a ROS bridge to go from your ROS2 to their ROS1 if you want to use mpatoros. That said, if you are accessing the MPA named pipes directly (or if you want to update their voxl-mpa-to-ros, which they've provided source code to), you won't need the ROS bridge and can use ROS2 directly. You can run MAVROS within ROS2 (it communicates over UDP to Mavlink). So really you just need a replacement for mpatoros or design your system to not depend on any of the MPA stuff. To run ROS2 on the drones themselves, you'll have to do a docker pull ros and setup a docker image that includes ROS2. Then either use a combination of network traffic (MAVROS via UDP) and the -v flag in docker (to import the MPA pipes) to try to get around using any ROS1 infrastructure provided by modalAI. In the worst case scenario, you may have to update the voxl-mpa-to-ros bridge. We don't use ROS2 because it's still buggy, but we did throw away the roskinetic image that ModalAI suggests using and rolled our own rosnoetic docker image, and life is much sweeter.

@Jeffrey-Mao voxl-mpa-ros2 is on the dev branch and not yet on stable. We expect more comprehensive testing and promotion to stable in the next few weeks. In the meantime, you can experiment with the latest code in the dev repository at your own risk