Thank you Alex!

@Alex-Gardner Ok, thanks much for running that. Since it built clean for you, that made it clear that there was something bad about my environment (the whole reason I'm down this rabbit hole!).
Anyway, my typical configuration is to ssh into my Linux machine from a W10 box using Cygwin/SSH. Apparently something in the build.sh script doesn't like that; hence my failures. When I build directly through the console of that Linux machine the build completes successfully.
Sorry for the confusion, and thanks to all for the responses.

@modaltb Any suggestion ?

Apologies. I actually have the simulator running on ROS1 Melodic.

@Chad-Sweet @modaltb what should be the fcu url for the updated mavlink server for mavros connection? Please help me to fix this

@hedd apologies as I was OOO for a few days. Feel free to send me an email at andrew.wilkins@ascendengineer.com

I would like to better understand what you are attempting to accomplish. It should not matter what VOXL version you are on.

@ModalAI could you answer this question?

@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

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

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

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/

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

@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 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
It actually turned out that the host-pc has ufw enabled.
Disabling ufw solved the issue.

Thanks

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

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? :)))

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

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!