Download Ros2
Vespasiano Jilg
(More generally, I find the promise of the Navigator library super appealing!! My dream is to run ROS2 on the py alongside with ardusub, subscribe to some of the mavlink messages from ros, and have direct control of some of the PWM outputs from ROS. Is that realistic? Are there conflicts to anticipate?)
I have been able to successfully use ROS 2 and the BlueROV2 with Blue. Right now it works with Humble, Iron, and Rolling. I have run it both on the Pi (I used a Pi 4) and from a topside computer. It offers support for the features that you mentioned (PWM control for thrusters, receiving mavlink messages, etc). I know of another student group that is also using this project for their research. You might also find the Orca4 project interesting, though it has not been used on hardware.
Did you manage to use the ros2 setup on the actual BlueROV2 or in simulation? Which is the software setup to do this? DO you have to flash a ubuntu 22.04 image on rasberry or the proposed blueos image?
Given that ROS 1 and ROS 2 are likely to be used in a mixed configuration for the foreseeable future, I think that a tag on answers.ros.org should help. And perhaps some kind of default filter that explicitly ignores or requires the ros2 tag?
I agree that answers.ros.org is probably the right place for this sort of thing, for now. However, I strongly agree with @gbiggs that there should be a consistent tag (ros2?) so that the questions are easily identified.
If the selection of one of these tags is mandatory I think there needs to be a distro-agnostic option. Some question are not related to a specific ROS distribution and it should be possible to ask such questions without being forced to select an arbitrary one from that list.
Similarly a question may be about a generic cmake usage, but depending on which rosdistro is being used the cmake version available is not the same. As we get to newer versions of cmake there are significant api improvements that may not have been available in older rosdistros and thus would not be captured.
On the DDS publisher side, I've utilized this repository to get the .idl equivalent of ros2 message types: -data-types . I've successfully generated the TypePlugin and TypeSupport classes, compiled and linked them to my application.
From the earlier posts, I understand that due to name mangling, we neet to prefix the topic names in DDS nodes with "rt/" in order to make them visible on ROS2, which I also did. The topic I'm publishing from the DDS node is visible on both RTI Admin Console and ROS2:
However, when I try to "echo" this topic, or write a ROS2 subscriber by using the built-in ROS2 trajectory_msgs/msg/JointTrajectory, I'm not receiving what DDS publisher is sending.
Trying to echo it on ROS2 gives the following:
My question is, should I use a different kind of syntax on the subscriber side for this built in ros message?
I'm using:
Subscriber: ROS2 Galactic (with default DDS vendor Eclipse Cyclone)
Publisher: RTI Connext Version: 6.0.1.
I suspect the issue may be the data type name and nesting in the IDL files.
The IDL types defined at -data-types were created for the initial ('Ardent') release of ROS2, and have since evolved in ROS2 to add an additonal layer of nesting and some naming changes.
Note the added layer of nesting under "dds_", and the trailing underscore on the struct name "Bool_".
This matches the types that are generated in the ROS2 build system. The expected data type may not be visible in RTI Admin Console when viewing a ROS2 node using rmw_cyclonedds_cpp due to CycloneDDS not supporting data type forwarding in its discovery info. The data type can be made visible by using an RMW/DDS combination that supports type forwarding, such as rmw_connextdds (or the older / deprecated rmw_connext_cpp).
One other note about the updated IDL types repository -- it includes a build option to create UNBOUNDED strings and sequences, instead of the default (bounded).
ROS2 data types that include strings and sequences are almost always unbounded, so these IDL data types should be built with this option for best interoperability with ROS2.
Note that BOUNDED publishers can send to UNBOUNDED subscribers without issue, but UNBOUNDED publishers cannot send to BOUNDED subscribers (the connection will be refused).
There's also an interop-demo repo at -rti/ros2-interop-demos that uses the above (updated) IDL repo for a few interoperability demos with ROS2, mostly using RViz or TurtleSim on the ROS2 side to show interop with native Connext DDS applications.
NOTICE: Any content you submit to the RTI Research Community Portal, including personal information, is not subject to the protections which may be afforded to information collected under other sections of RTI's Web site. You are entirely responsible for all content that you upload, post, e-mail, transmit or otherwise make available via RTI Community Portal. RTI does not control the content posted by visitors to RTI Community Portal and, does not guarantee the accuracy, integrity, or quality of such content. Under no circumstances will RTI be liable in any way for any content not authored by RTI, or any loss or damage of any kind incurred as a result of the use of any content posted, e-mailed, transmitted or otherwise made available via RTI Community Portal. Read the complete Terms prior to use.
First of all thanks for answering me, and yes and this is the part where I struggle. I tried to convert and adapt the posix_sitl.launch file.
To begin I used GitHub - aws-robotics/ros2-launch-file-migrator: This package takes a ROS1 XML launch file and converts it to a ROS2 Python launch file which allows me to convert a ROS .xml launch file into a ROS2 .py launch file.
But this errors occurs :
launch.invalid_launch_file_error.InvalidLaunchFileError: Caught exception when trying to load file of format [py]: "package 'mavlink_sitl_gazebo' not found, searching: ['/opt/ros/foxy']
The only issue that keeps us from doing so is that since, as @TSC21 said, PX4 does not at the moment build as an Ament package, it does not install its executables and resources to a ROS 2 workspace so we had to hard-code the location of the PX4 codebase to find the executable.
We would be happy to share this launchfile with you, and if you hopefully had some time on your hands to help make PX4 build as an Ament package, it would become possible to use get_pkg_share_directory to retrieve the stuff instead of a hard-coded path and thus make this launchfile available to the larger PX4 community by contributing it.
As I already said, we would love to contribute this launchfile, the only thing is that since we got it working for ourselves we do not have enough time on our hands to modify the PX4 build system to be able to contribute it. We are a very small team.
I am looking for a solution to a problem similar to this one, as I need to control multiple vehicles running PX4 via ROS2. Could you please share the launch file you talked about? It would be really helpful both to solve my problem and to understand how to write new launch files for PX4 with ROS2.
You will notice that we were forced to use hard-coded paths, that you will need to update and prevent your package from being used like a regular, generic, ROS2 package. We had to do this because PX4 is not (yet) compiled as a ROS2 package and thus none of the executable, model files or Gazebo plugins are copied to the install space upon colcon build. Fixing that will allow fixing this launchfile.
Hi @befaro and @deb0ch , first of all thanks for sharing your code.
I am trying to use it in my project with ROS Humble, but I can not understand how to use it, because PX4-Autopilot firmware can not be build with colcon, so when I try to run your launch file I get the following error:
After manually fixing the paths to nmea-msgs, geographic-msgs, diagnostic-updater, and robot-localization it finally gets past zed_components only to get stuck on the same error when building the zed_wrapper package.
System dependencies have not been satisfied:
aptros-humble-ament-lint-auto
aptros-humble-ament-cmake-copyright
aptros-humble-ament-cmake-cppcheck
aptros-humble-ament-cmake-lint-cmake
aptros-humble-ament-cmake-pep257
aptros-humble-ament-cmake-uncrustify
aptros-humble-ament-cmake-xmllint
aptros-humble-stereo-msgs
aptros-humble-launch-ros
aptros-humble-shape-msgs
ERROR[zed_ros2]: Cannot locate rosdep definition for [zed_wrapper]
rosdep key : zed_wrapper
OS name : ubuntu
OS version : jammy
Data:
ERROR[zed_components]: Cannot locate rosdep definition for [zed_interfaces]
rosdep key : zed_interfaces
OS name : ubuntu
OS version : jammy
Data:
ERROR[zed_wrapper]: Cannot locate rosdep definition for [zed_components]
rosdep key : zed_components
OS name : ubuntu
OS version : jammy
Data:
So it seems there were some dependencies that were not being installed. I manually installed the missing dependencies but that also did not help. In fact now I get a warning when trying to build the zed-wrapper so maybe I should remove the manually added dependencies?
sudo apt install ros-humble-ament-lint-auto ros-humble-ament-cmake-copyright ros-humble-ament-cmake-cppcheck ros-humble-ament-cmake-lint-cmake ros-humble-ament-cmake-pep257 ros-humble-ament-cmake-uncrustify ros-humble-ament-cmake-xmllint ros-humble-stereo-msgs ros-humble-launch-ros ros-humble-shape-msgs
Robot Operating System (ROS or ros) is an open-source robotics middleware suite. Although ROS is not an operating system (OS) but a set of software frameworks for robot software development, it provides services designed for a heterogeneous computer cluster such as hardware abstraction, low-level device control, implementation of commonly used functionality, message-passing between processes, and package management. Running sets of ROS-based processes are represented in a graph architecture where processing takes place in nodes that may receive, post, and multiplex sensor data, control, state, planning, actuator, and other messages. Despite the importance of reactivity and low latency in robot control, ROS is not a real-time operating system (RTOS). However, it is possible to integrate ROS with real-time computing code.[3] The lack of support for real-time systems has been addressed in the creation of ROS 2,[4][5][6] a major revision of the ROS API which will take advantage of modern libraries and technologies for core ROS functions and add support for real-time code and embedded system hardware.
c80f0f1006